An organisation adopts delivery metrics and teams begin optimising the numbers rather than the outcomes. What went wrong, and how should the metrics be used?
Show the full answer Hide the answer
What went wrong
The metrics became targets, so they stopped measuring what they measured. Deployment frequency rises because teams deploy trivial changes separately. Lead time falls because work is decomposed for the metric rather than for delivery. Change failure rate falls because incidents are classified as something else. Time to restore falls because the clock starts later.
Every one of these is an improvement in the number and a degradation or a nullity in reality.
Why these four metrics are nonetheless valuable
They resist gaming better than most because they are in tension. Deployment frequency and lead time measure speed; change failure rate and restore time measure stability. Optimising one pair at the expense of the other shows up in the other pair.
They must be used as a set. A team with excellent frequency and a rising failure rate is not improving, and reporting the four together makes that visible.
How they should be used
1. As a diagnostic for a team, by that team, not as a comparison between teams. Different products have legitimately different profiles — a team shipping a regulated batch system will not and should not match a web front end.
2. As a trend, not an absolute. Improvement in a team's own trajectory is meaningful; a league table is not, and it produces exactly the gaming behaviour described.
3. To locate constraints. Long lead time with high deployment frequency points at wait time before development — backlog, decisions, handoffs — rather than at engineering. That diagnostic use is where the value is.
4. Alongside outcome measures — user-facing reliability, business results, and flow efficiency, the ratio of active work time to elapsed lead time, which frequently reveals that engineering is not the constraint at all.
The framing that keeps them honest
These metrics are a health check, not a performance evaluation. The moment they are used for comparison or compensation, they become the thing being optimised and stop describing the system — which is the general property of any metric attached to consequences, and the reason to keep them diagnostic.