# DORA metrics are not performance metrics > Lead time, deployment frequency and change failure rate tell us a great deal about delivery systems. They tell us surprisingly little about the performance of individual engineers. By Matthew D. Webb · 2026-03-19 · 6 min read Canonical: https://mdwebb.io/articles/dora-metrics-are-not-performance-metrics/ AI involvement: Used to draft and revise this article, images and diagram included. --- Few engineering metrics have spread as far, or as fast, as DORA. Walk into a delivery organisation of any real size and you'll find the four numbers pinned to a dashboard somewhere, usually next to a red-amber-green status nobody quite trusts. That popularity is mostly deserved. Deployment frequency, lead time for changes, change failure rate and mean time to recovery are a genuinely useful way to take the temperature of a delivery system. They tell you whether software can move from idea to production safely, predictably and often, which is exactly the sort of thing a leader wants to know. The trouble starts the moment someone tries to use them for a job they were never built to do: grading the people. ## What DORA actually measures At their core, the four metrics measure the *capability of a delivery system*. They answer a tidy set of questions. How quickly can we get a change out? How often do we deploy? How frequently does a change break something? How fast do we recover when it does? All worth knowing. Read together, they tell you where a delivery pipeline is bottlenecked, where it's fragile, and where the process is costing you time and nerve. What they do not measure is the productivity of a specific engineer, team or manager. That distinction sounds pedantic written down. It turns out to be the whole game, because the instant DORA gets repurposed as a scorecard for individuals, every number on it starts lying to you. ## Software delivery is a system Take lead time, the one most often waved around as a proxy for how "fast" a team is. Lead time is shaped by architecture, testing strategy, release process, team structure, dependencies, risk controls and roughly a dozen product decisions made by people who will never see the dashboard. Pull the clock apart and the point makes itself. The bit an individual actually controls, sitting down and writing the change, is usually a thin sliver. The rest is the system queueing: waiting on review, waiting on CI, waiting on an approval, waiting for a deploy window that opens twice a week.
A single horizontal bar from commit to production. A small first segment is the engineer writing code; the long remainder is the delivery system waiting: review queue, CI, release approval, deploy window and verification.
An engineer can be exceptional and still sit inside a system that ships at a crawl. Equally, a thoroughly average one can look like a machine inside a well-built delivery organisation. When a change takes three weeks to reach production, the explanation is almost never a single person. It's buried somewhere in the system, which is precisely where DORA was pointing all along. ## The trouble with comparing teams Sooner or later someone asks the obvious question: which team has the best DORA metrics? It sounds reasonable. It's usually a trap. Picture two teams. One owns a customer-facing checkout platform handling millions of transactions; the other owns an internal reporting dashboard a few hundred employees log into on a Tuesday. Should they deploy at the same cadence? Carry the same change failure rate? Of course not. The cost of getting it wrong isn't remotely comparable, and the metrics that look prudent on one are negligence on the other. Rank them on a single leaderboard and you strip out the context that gave the numbers any meaning in the first place. I've written at more length about [why most engineering metrics fail](/articles/why-most-engineering-metrics-fail/) when they're turned into targets, so I won't relitigate Goodhart's Law here. The short version: the moment leadership starts managing the number instead of the system behind it, people optimise the number - and they are remarkably good at it. Deployment frequency targets breed artificially split releases. Lead time targets breed thinner reviews and deferred testing. The dashboard improves. The system doesn't. ## High performance and recklessness can look identical Here's the part that should make anyone nervous about using DORA as a verdict. A mature, disciplined organisation produces frequent deployments, low lead times and fast recovery. So does a reckless one - right up until the moment something goes wrong. For a good long while the two are genuinely indistinguishable on the dashboard. The difference only surfaces when a change fails, and you find out whether all that speed was built on solid testing and observability or on hope and a prayer. The numbers were never the position; they were the move count. You cannot judge the move without seeing the board it was played on. Which is the entire problem with treating any of this as a performance grade. The metrics give you a signal. They do not give you the *why*, and the why is the only thing worth knowing. ## Measure the system, coach the people The leaders who get value out of DORA treat the numbers as the opening line of a conversation, not the closing argument. A jump in lead time is interesting. A creeping change failure rate is interesting. A drop in deployment frequency is interesting. None of them is a verdict. Each is an invitation to go and find out what's actually happening. And what's actually happening is nearly always systemic. The architecture is too tangled. The release process is too manual. The test suite is too slow to trust. Ownership boundaries are vague, dependencies are a mess, and three teams are quietly blocked on a fourth. You do not fix any of that by pulling an engineer into a one-to-one and asking them to shorten their personal lead time. You fix it by improving the system they're standing in. That's the line worth holding. Measure the system; coach the people. The two require completely different instruments, and DORA is firmly an instrument for the first. ## The value of DORA None of this makes DORA worthless. Quite the opposite: used properly, it's some of the most useful operational telemetry an engineering organisation has. It surfaces friction, exposes fragility, and tells you whether the work you're doing to improve delivery is actually landing. Used improperly, it becomes one more mechanism for ranking teams, comparing individuals and polishing a dashboard while the real system goes unexamined. The distinction is simple enough to state and astonishingly easy to lose. DORA measures how well software moves through an organisation. It does not measure the worth of the people building it. Confuse those two, and you'll optimise the number while demoralising the very people the number depended on. ## Further reading - [DORA metrics: the four keys (and beyond)](https://dora.dev/guides/dora-metrics-four-keys/): the canonical definitions straight from the research programme, including how the original four grew into the current five-metric model. - [Accelerate: The Science of Lean Software and DevOps](https://itrevolution.com/product/accelerate/): Forsgren, Humble and Kim's book; the research that started all of this, and a useful reminder that the findings are about capabilities, not scoreboards. - [Accelerate State of DevOps Report 2024](https://dora.dev/research/2024/dora-report/): the latest annual report, worth reading for how DORA frames the metrics as signals about a system rather than a verdict on people. - [Use the Four Keys to measure your DevOps performance](https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance): Google Cloud's practical guide, with calculation methods and the open-source pipeline if you actually want to instrument this.