Five Metrics, Not Four

Part 7 closed the code half of this series; from here the instruments point at delivery. And the first delivery instrument is one almost every engineering organisation already claims to own — which is exactly the problem, because most of the DORA dashboards I have been shown are stale in three ways at once. They track four metrics when the research now defines five. They quote benchmark thresholds from a report vintage two cycles old. And they group the metrics in a way DORA itself no longer uses. None of these errors is embarrassing individually — the research moved and the dashboards did not — but together they mean the most-cited numbers in software delivery are very often being read off an out-of-date instrument. This part is DORA as it stands, with every figure pinned to the report year it came from.

Whose numbers these are

DORA — DevOps Research and Assessment — is a research programme founded by Nicole Forsgren, Jez Humble and Gene Kim, and part of Google Cloud since 2018. Its annual State of DevOps surveys have accumulated, across a decade of research as reported around the 2024 report, responses from more than 39,000 professionals — which is why its findings carry a weight that vendor benchmarks do not. Everything in this part is their work, read from dora.dev as I write; the commentary on how to hold the numbers is mine.

That distinction matters more for DORA than for any other framework in this series, because DORA suffers from a specific failure mode: it is famous enough to be transmitted by folklore. Most teams did not learn their DORA thresholds from a DORA report; they learned them from a slide that cited a blog that summarised a report from some unrecorded year. Folklore does not carry version numbers. Reports do.

The four you can already name

The familiar quartet, briefly and in my own words:

• Deployment frequency — how often code reaches production. The number is a proxy for batch size: teams that deploy often are shipping smaller changes, carrying less risk per change, and getting feedback sooner — and they have been forced to build the automation that makes all of that safe.
• Change lead time — the elapsed time from a commit to that commit running in production. (You may know it as “lead time for changes”; change lead time is the current official name.) It measures the pipeline end to end: review, CI, approvals, deployment — and long lead times are a map of where the friction lives.
• Change fail rate — the share of deployments that cause a production failure needing remediation: a rollback, a hotfix, a patch. This is the reliability counterweight to the two throughput numbers above.
• Failed deployment recovery time — how quickly service is restored after a deployment fails. Failures are a certainty at any deployment cadence; this measures whether one costs you minutes or days.

Four dials, and for years the folklore version of DORA stopped here. The research did not.

The fifth dial counts the do-overs

The 2024 DORA report added a fifth metric: deployment rework rate, defined by DORA as “the ratio of deployments that are unplanned but happen as a result of an incident in production”. The 2025 report then published benchmarks for all five, making the fifth metric a fully-fledged peer of the original four rather than a footnote.

Here is why I think it earns its place on the dashboard. Deployment frequency, on its own, cannot tell the difference between a team shipping ten features a day and a team shipping ten emergency patches a day — both look elite on that single dial. Rework rate is the disambiguator: it asks how much of your deployment cadence is planned progress and how much is unplanned fixing of what just shipped. A high rework rate means the pipeline is not catching defects before production, and the team's capacity is being spent buying back its own recent past. If your dashboard still shows four metrics, this is the one it is silently miscounting as throughput.

Throughput and instability, regrouped

The five metrics now sit in two groups, and the current grouping is not the one most dashboards inherited. Per DORA's current guide: throughput covers change lead time, deployment frequency and failed deployment recovery time; instability covers change fail rate and deployment rework rate.

The surprise is recovery time filed under throughput. The older mental model — the one I carried myself until I re-read the guide while writing this part — put recovery on the stability side, as a measure of how bad failures are. The regrouping reads better the longer you look at it: recovery time is really a measure of how quickly the team can move again — the speed of shipping the fix is governed by the same pipeline that governs the speed of shipping anything. What marks a team as unstable is not that recovery is slow; it is how often deployments fail and how often they have to be done over. Speed dials on one side, failure-frequency dials on the other. If your dashboard groups recovery under “stability”, it predates the change — worth fixing, because the grouping shapes which numbers get read together.

Benchmarks have vintages

Now the thresholds, which is where dated citation stops being pedantry and starts being the whole game. The most recent classic four-tier benchmark tables are from the 2023 State of DevOps report:

Two things about this table. First, the elite change lead time is less than one day. The “under one hour” figure still circulating on slides and in gate configurations is the 2021-era tier — a different survey population, a different year, a stricter cut. I have seen the two vintages quoted in the same deck without anyone noticing they disagree by a factor of twenty-four. Second, the four-tier ladder itself was retired after 2023: the 2024 report grouped respondents into performance clusters instead, and the 2025 report published per-metric benchmarks for all five metrics alongside profile-based analysis. The table above is still the most useful calibration reference of its kind — but only if it is labelled with its year.

Which yields this part's rule of thumb: a DORA figure without a report year attached is not a benchmark; it is a rumour. Date every threshold you quote, in the dashboard itself, and half the arguments about “what elite means” dissolve on contact.

Seven shapes of a team

What replaced the elite-to-low ladder is worth knowing in its own right. The 2025 DORA report describes seven team archetypes — profiles that combine delivery performance with human and organisational factors, rather than ranking teams on a single axis. The names are DORA's; the one-line readings are mine:

1. Foundational Challenges — the basics are still being fought for, and process gaps swallow everything else.
2. Legacy Bottleneck — an ageing, unstable estate sets the agenda; the team spends its week reacting to it.
3. Constrained by Process — capable engineers losing their time to workflow friction rather than to the technology.
4. High Impact, Low Cadence — what ships is valuable; it simply does not ship often.
5. Stable and Methodical — deliberate, dependable delivery that keeps its quality intact.
6. Pragmatic Performers — quick, well-supported delivery without much drama.
7. Harmonious High-Achievers — pace, reliability and team health reinforcing one another.

The shift from ladder to archetypes changes what the framework is for. A rung on a ladder tells you your rank; an archetype tells you your constraint — which of several distinct failure shapes your organisation most resembles, and therefore where intervention would actually bite. A Legacy Bottleneck team and a Constrained by Process team might post similar lead times for entirely different reasons, and the remedies barely overlap. That is diagnosis, which is what this series keeps insisting metrics are for.

The warning printed on the tin

One more thing DORA says about its own metrics, and the folklore reliably drops it: DORA explicitly warns against cross-team comparison, and recommends tracking a single team's metrics over time instead. The researchers who built the most widely adopted delivery benchmark in the industry are telling you not to use it as a league table.

They are right, and part 1 explained the mechanism: the moment five diagnostic dials become five scoreboards, teams optimise the dials. Deployment frequency is trivially inflatable with empty deployments; lead time bends when work is sliced thin enough; and every one of those adaptations destroys the correlation that made the metric informative. Context differences between teams — domain, estate age, compliance load — also mean the comparison was never fair to begin with. One team, trended over time, against its own history: that is the reading DORA's own research supports.

The checklist, then. Five metrics, not four. Every threshold labelled with its report year. The current throughput/instability grouping. Archetypes read as diagnosis, not rank. And no leaderboards — on the authority of the people who made the numbers.

DORA instruments the deployment pipeline: from commit onward. But most of a work item's life happens before any commit exists — in queues, in wait states, in the gap between “asked for” and “started” — and measuring that half needs a different set of instruments and one very old piece of mathematics. Next, flow metrics and Little's Law.