TL;DR: A metric is worth having only if it makes delivery easier to discuss honestly — revealing waiting, rework, risk, and impact rather than rewarding calendar theater. Use a small set read in combination, never rank individuals by output, watch for Goodhart's Law the moment a number becomes a target, and attach every metric to a review ritual — a number nobody discusses regularly is decoration.
Measure flow, not busyness
Most engineering metrics programs fail for the same reason: they measure what is easy to count instead of what is true. Lines of code, commit counts, story points closed, hours logged — all trivially collectible, all nearly worthless, because none of them distinguishes a team unblocking a critical flow from a team polishing something nobody asked for.
A good metric makes delivery easier to discuss honestly. It should reveal waiting, rework, risk, and impact — the things that actually determine whether a product improves. It should never reward calendar theater: showing up, looking busy, closing tickets that were never the bottleneck.
A metrics program is not measuring engineering. It is measuring the parts of engineering that were easy to instrument — which is a very different thing, and worth remembering every time a chart drives a decision.
The DORA baseline, applied honestly
The four DORA metrics — deployment frequency, lead time for changes, change failure rate, time to restore service — earned their reputation because years of research tied them to organizational outcomes, not because they are complete. I use them as a floor, not a ceiling, and with two caveats that the research itself is explicit about.
- They are outcomes, not levers. You cannot improve deployment frequency directly; you improve the pipeline, the test suite, the review process, and frequency rises as a consequence. Managing to the outcome metric directly produces exactly the gaming this whole article warns about.
- They describe the system, not the individual. Lead time is a property of the pipeline a team shares. Attributing it to a person is a category error that DORA's own authors have repeatedly and publicly disowned.
Used as a floor, DORA tells you whether the pipeline as a whole is healthy. It does not tell you where the friction is, why reviews stall, or whether the team is burning out to hit the numbers — for that you need the qualitative complement below.
Read metrics together
One metric lies easily, almost always by omission. A small set read in combination gives context that no single number can. Lead time without a quality signal can push rushed, risky work — the fastest way to ship is often to skip the parts that prevent incidents. Quality without a flow signal can hide slow, cautious delivery dressed up as diligence.
I pair every flow metric with a counterweight so improving one cannot silently damage the other:
| Flow metric | Paired counterweight | What the pair reveals |
|---|---|---|
| Lead time for changes | Change failure rate | Are we shipping fast because we are good, or because we stopped checking? |
| Deployment frequency | Time to restore service | Does shipping often come with the ability to recover fast when it breaks? |
| Review turnaround time | Escaped defect rate | Is fast review careful review, or rubber-stamping? |
The SPACE framework formalizes this instinct across five dimensions — satisfaction, performance, activity, communication, efficiency — precisely because any single one, pursued alone, degrades the others. You do not need all five dashboards; you need the discipline of never reading a flow number without its quality partner in the same sentence.
Goodhart's Law is not theoretical
"When a measure becomes a target, it ceases to be a good measure" is not a warning label — it is a description of what I have watched happen, repeatedly, the moment a metric graduates from observation to evaluation criterion. A few patterns recur closely enough to name:
- PR splitting for velocity. Once "PRs merged" becomes visible in a dashboard someone reviews, PRs get smaller — sometimes because that is genuinely good practice, sometimes purely to inflate the count with no corresponding gain in delivered value.
- Story point inflation. Track "points delivered" as a success signal and points quietly grow over a few sprints with no change in actual scope. The number goes up; nothing else does.
- Batching to hit release cadence. A deployment-frequency target met by bundling five days of work into one Friday release to hit the weekly count — the metric improves while the actual practice it was meant to encourage gets worse.
- Ticket-closing theater. Splitting one piece of work into many small tickets purely to move a "tickets closed" number, adding process overhead with no delivery benefit.
The tell that a metric has become a target: someone can improve the number without the underlying reality improving at all. If that path exists and is easier than the honest path, people will find it — not from bad faith, but because incentives are stronger than intentions.
Avoid reporting traps
- Do not rank individuals by output count — flow metrics describe systems and teams, not people, and individual rankings optimize for the wrong unit entirely.
- Do not hide blocked work in averages — a mean lead time looks fine while three items sit stuck for a month; report distributions and outliers, not just the center.
- Do not measure what no one can influence — a metric with no owner and no lever produces anxiety, not action.
- Do not use metrics without a review ritual — a number nobody looks at regularly is not a metric, it is decoration on a dashboard.
- Do not present metrics without their counterweight — a lead-time chart alone is an invitation to game it.
A review ritual that keeps metrics honest
Metrics stay honest only inside a ritual that treats them as a starting question, not a verdict. The format I run: fifteen minutes, biweekly, three questions per metric pair — what changed, do we believe the number reflects reality, and what would we investigate before acting on it. That third question is the one that catches gaming before it hardens into a habit.
Two rules make the ritual trustworthy rather than another performance. First, the team that owns the numbers reads them first, before any report goes upward — nobody should learn what their own metrics say from a slide a manager built. Second, "we do not know why this moved" is an acceptable, expected answer some weeks; a ritual that always produces a tidy explanation is generating stories, not insight.
Introducing metrics without breaking trust
How a metrics program launches determines whether it survives contact with a bad quarter. A few sequencing choices have mattered more than any dashboard tool:
- Baseline before target. Measure for a month with zero targets attached, purely to learn the current shape of the system. A target set against an unknown baseline is a guess wearing a number.
- Team-level before individual-adjacent. Start where gaming does the least damage and trust is easiest to build; individual-level metrics, if ever used, need a much higher bar of justification.
- Explain the "why" before the "what". A team that understands why lead time matters to them will not need policing; a team only told to lower a number will find the cheapest way to lower it.
- Retire metrics that stopped teaching anything. A dashboard grown over years and never pruned is not rigor, it is clutter — and clutter is where bad numbers hide from scrutiny.
Summary
- Measure flow and risk, not busyness — a good metric reveals waiting, rework, and impact.
- Use DORA as a floor: outcomes of the system, never levers, never attributed to individuals.
- Always read a flow metric next to its quality counterweight — neither alone tells the truth.
- Expect Goodhart's Law the moment a metric becomes a target; watch for the cheap path to a better number.
- Never rank people by output, hide blocked work in averages, or track what nobody can influence.
- Attach every metric to a biweekly ritual owned by the team whose work it describes.