An organisation adopts the four DORA metrics and delivery does not improve. What are the metrics for, and how are they commonly misused?

What they are and what they are for

Deployment frequency, lead time for changes, change failure rate, and time to restore service.

They are paired deliberately: the first two measure speed, the second two measure stability, and the research finding that matters is that they move together rather than trading off. Organisations that deploy frequently also fail less and recover faster, because the same practices — small changes, automation, fast feedback — produce both.

Their purpose is diagnostic: to show where a delivery system is constrained, so that improvement effort is directed rather than guessed.

How they are misused

• As targets rather than as diagnostics. Once deployment frequency is a goal, teams deploy trivially to raise it — the metric improves and nothing else does. This is the standard failure of any measure that becomes a target.
• Comparing teams. A team maintaining a regulated batch system and a team running a web front end have legitimately different profiles, and ranking them produces gaming and resentment rather than insight. Compare a team against its own trend.
• Measuring only two. Deployment frequency and lead time without change failure rate rewards recklessness; the pairing is what makes them safe.
• Measured on the wrong scope — per repository or per pipeline rather than per user-facing change — which misses everything that happens between teams.
• Treated as the whole picture. They measure the delivery pipeline. They are silent on whether the right things are being built, and silent on coordination cost between teams — which is frequently the actual constraint.
• Instrumented and then not acted upon, which is the commonest outcome: a dashboard, a quarterly review, and no change to the system that produces the numbers.

What is missing, and matters

• The number of services and teams that must change together for a typical feature. Lead time in a large organisation is usually dominated by waiting for other teams, and this is the metric that exposes it. It is rarely instrumented.
• Time spent on unplanned work and operational toil.
• Deployment lead time decomposed into coding, review, waiting for environments, waiting for approval, and waiting for other teams — because the aggregate does not tell you what to fix.
• Reliability from the user's perspective, which is the SLO, and is a different question.

Using them properly

Instrument, decompose, find the largest single delay, remove it, measure again. The decomposition is the whole value: an eight-day lead time that is six days waiting for a manual approval and two days of everything else has an obvious intervention, and the aggregate number conceals it.

Then re-decompose, because removing the largest delay promotes a different one, and the second constraint is rarely the one anybody predicted.