The Measurement Trap
Every engineering leader eventually asks: how do we know if our team is productive?
The question is reasonable. The answers most teams reach for are not.
Lines of code. Tickets closed. PRs merged. Story points. These metrics are easy to measure and nearly useless, worse than useless, because optimizing for them actively harms the outcomes you actually care about.
The problem isn't measurement. It's measuring the wrong things.
What Good Looks Like: DORA Metrics
The DORA research program (now part of Google Cloud) identified four metrics that actually correlate with business outcomes:
| Metric | What it measures |
|---|---|
| Deployment frequency | How often you ship to production |
| Lead time for changes | Commit to production time |
| Change failure rate | % of deploys that cause incidents |
| Time to restore service | How fast you recover from incidents |
Elite teams deploy multiple times per day with a lead time under one hour. They have change failure rates below 5% and restore service in under an hour.
These metrics are hard to game. You can't inflate deployment frequency without actually deploying. You can't fake a low change failure rate without actually shipping stable code.
The SPACE Framework
DORA measures the system. SPACE tries to measure the individual and team experience:
- Satisfaction: Are engineers happy with their work and tools?
- Performance: Is the work having the intended outcomes?
- Activity: What are engineers doing? (NOT the primary metric)
- Communication: How well does knowledge flow through the team?
- Efficiency: Can engineers do focused work without interruption?
The key insight from SPACE research: you need at least one metric from three different dimensions. Any single metric tells an incomplete story.
The Metrics That Actually Start Conversations
In practice, the metrics we've found most useful are:
Cycle time: the time from "first commit" to "merged to main." A rising cycle time means PRs are getting too big, reviews are slow, or there's too much back-and-forth. Each of those has a different fix.
Review turnaround time: how long PRs wait for a first review. Anything over 24 hours starts creating context-switching costs for the author.
Deploy frequency: if it's declining, ask why. Fear of breaking things? CI is too slow? Release process has too many gates?
Incident frequency and severity: the ultimate lagging indicator of technical health.
What Metrics Can Never Tell You
No metric captures:
- Whether an engineer is doing their most important work
- The quality of architectural decisions
- How much time someone spent mentoring
- Whether a feature was the right thing to build
This matters because the best engineers often show up as "unproductive" by naive metrics. They're writing design docs, unblocking teammates, reviewing architecture. None of that shows in deployment frequency.
The Right Way to Use Metrics
Metrics are for the team, not about the team.
Share them openly. Review them in retrospectives. Use them to start conversations: "our cycle time increased 40% last quarter. What changed?" Not to evaluate individuals or justify headcount decisions.
The moment engineers feel they're being measured, they optimize for the metric. And the metric stops measuring what you thought it was.
The Actual Goal
The goal isn't high DORA metrics. The goal is software that works, shipping at a pace that's sustainable, built by engineers who aren't burning out.
Metrics are a compass, not a destination. Point them at your problems, not at your people.