Leadership · Metrics
How I measure engineering team health.
I track three groups of numbers: how fast the team delivers, how healthy the team and its systems are, and whether the work reaches users. With AI assistants now writing much of the code, a fourth question matters too: is AI actually making the team better, or just busier?
Pair every speed metric with a quality or health metric, and include at least one number users would recognize. Build on established frameworks like DORA and SPACE rather than inventing your own. To judge AI assistants, watch lead time, change failure rate and review time, never lines of code.
The metrics I track
| Group | Metric | The question it answers |
|---|---|---|
| Delivery | Lead time for changes | How long from a commit to it running in production? |
| Delivery | Deployment frequency | How often can we safely ship? |
| Delivery | Change failure rate | How often does a release cause a problem? |
| Health | Sprint say/do ratio | Do we deliver what we commit to? |
| Health | Time to onboard | How fast does a new engineer ship their first real change? |
| Health | Data parity | Do our systems agree with each other? |
| Impact | Core Web Vitals | Is the product fast for real users? |
| Impact | Reporting lead time | How long from a business question to a trusted answer? |
Start from established frameworks
You don't need to invent a measurement system. Two frameworks cover most of what matters:
- DORA metrics from Google's DevOps Research and Assessment program: deployment frequency, lead time for changes, change failure rate and time to restore service. They measure how well a team delivers software.
- The SPACE framework looks at productivity more broadly: satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow. It is a reminder that activity alone is never the full picture.
My list above uses DORA for delivery and adds the health and impact numbers that matter for the kind of platforms I build.
What the numbers looked like in practice
- Impact at Fincaraiz. During the migration to microservices, our user-facing number was Largest Contentful Paint. We kept it under 3 seconds, the same as the legacy site, which protected both user experience and search rankings.
- Data parity in lead distribution. In our B2B lead distribution system, we reconciled every lead in our reports against the partner's CRM and held a 100% match.
- Reporting lead time at Cedar Planters. When building the data platform, the key question was how fast a business question became a trusted dashboard.
Measuring the impact of AI assistants
Most teams now use AI coding assistants. The temptation is to measure them by volume: more pull requests, more lines, more tickets closed. Those numbers go up easily and prove very little. What I watch instead:
| Watch | Healthy sign | Warning sign |
|---|---|---|
| Lead time for changes | Falls, and stays down | Coding gets faster but lead time doesn't move |
| Change failure rate | Stays flat or falls | Rises as more code ships |
| Review time | Stable | Pull requests pile up waiting for review |
| Rework | Stable | More code is rewritten or reverted soon after merging |
| Developer satisfaction | People say they spend less time on toil | People feel they review more than they build |
A common pattern is the bottleneck moving: AI speeds up writing code, and the queue shifts to review and testing. That is not a failure, but it means the next improvement is in the review process, not in more generation.
How to collect them
Most of these numbers already live in your tools. Deployment and lead time data come from your CI/CD pipeline and Git history on GitHub or GitLab; sprint data from Jira or a similar tracker; web performance from real-user monitoring and Google Search Console. If you don't want to build dashboards yourself, engineering analytics platforms combine these sources for you. They focus on different things:
| Platform | What it is best at | Use it when |
|---|---|---|
| DX | Combines regular developer surveys with data from your systems, to measure developer experience and productivity, including the adoption and impact of AI tools | You want to know where engineers lose time and whether AI assistants are really helping, not only what the pipeline says |
| LinearB | Delivery analytics from Git and project tools: DORA metrics, cycle time by stage, pull request size and review time, plus automation for parts of the pull request workflow | You want to find and fix delivery bottlenecks, especially in code review |
| Swarmia | DORA and flow metrics, a view of how effort splits between new features, maintenance and unplanned work, and team working agreements with Slack reminders | You want a team-level view of flow and focus, and help keeping agreed habits |
Whichever you choose, start with the question you want answered, agree with the team on what will be measured and why, and roll it out at team level first. Free options go a long way too: GitHub and GitLab insights, and Jira's cycle time and control chart reports. AI assistants are also useful here: give one an export of your ticket or pull request data and ask it to find where time goes, then verify the pattern yourself.
How I use them
- A number that moves the wrong way starts a conversation with the engineers involved. The data shows where; they explain why.
- I look at trends across sprints and releases, not single values.
- Metrics describe the system, never individual performance. The moment people feel judged by a number, they start optimizing the number.
When a delivery number moves the wrong way, this is how I find the cause: Finding delivery bottlenecks with lead time and cycle time.
Get my next case studies and articles in Google Search.