A team measures deployment frequency, lead time, change failure rate and recovery time. How should these be used, and how are they misused?

How they should be used

As a diagnostic of the delivery system, tracked as a trend, at team level. They describe the health of the pipeline from commit to production, and they are genuinely predictive: teams that deploy frequently in small increments have lower failure rates and faster recovery, because changes are individually attributable and individually reversible.

The most useful is lead time, because it aggregates everything — review latency, build time, test duration, environment availability, approval steps — and its components identify the constraint.

How they are misused

• As individual or team performance targets. They are then gamed immediately: deployment frequency by splitting commits, lead time by starting the clock later, change failure rate by not classifying incidents as change-related. The measurement stops describing reality within a quarter.
• Compared across teams with different contexts. A team shipping a mobile app through an app store review cannot have the same deployment frequency as a web team, and the comparison is meaningless.
• Treated as outcomes. They are output measures. A team can double its deployment frequency while shipping features nobody uses, and presenting them to leadership as evidence of value invites the reasonable response that none of it appears in business results.
• Optimised in isolation. Deployment frequency without change failure rate encourages recklessness; change failure rate alone encourages caution. The set must be read together, which is the point of there being four.

What to add

• A business outcome measure, so the delivery system's health is connected to whether the work mattered.
• Review latency separately, since it is frequently the largest component of lead time and is invisible inside it.
• Time from incident start to detection, which is usually a bigger lever than time to fix and is under-examined because it is less interesting.

The honest framing

These measure whether the delivery system is capable, not whether it is being used well. A capable system is a precondition for responding to what outcome measurement tells you — which makes them necessary and insufficient, and worth saying explicitly when they are presented.