Leadership wants DORA metrics on a dashboard for every team. How do you use them well, and how would each one be gamed?

The four keys, the current five, and why they come in pairs

The original four keys are deployment frequency, lead time for changes, change failure rate, and time to restore service after a failed change. DORA now publishes five, and two of the names have moved with them. Throughput is measured by change lead time, deployment frequency and failed deployment recovery time, which is the renamed time to restore. Instability is measured by change fail rate and deployment rework rate, the proportion of deployments that need unplanned remediation afterwards without ever being declared an incident. Rework rate is the genuine addition, and it closes the gap a team under pressure has always hidden in: work that was quietly redone rather than formally failed.

Say both vocabularies out loud, because most leadership dashboards still ask for the original four under the original names, and a candidate who only knows the current five will keep answering a question nobody in the room asked.

Presenting any of this as a flat list is the commonest weak answer. The design point is the pairing. The research finding that made these interesting is that throughput and stability move together in high performers rather than trading off, which contradicted decades of assumption that going faster necessarily meant breaking more. That is also what makes the set partly self-defending: a team that pushes deployment frequency up by skipping tests will show it in change fail rate, and a team that suppresses change fail rate by deploying rarely will show it in the throughput side. Renaming the measures did not disturb that argument at all — you read one side against the other, or you read neither.

How each one is gamed

None of that makes them ungameable, only harder to game quietly.

Deployment frequency inflates by redefining a deployment. Split one release into six pipeline stages and count each, or count deployments to a staging environment, and the number sextuples with no change in delivered value. Anchor it to production and to a user-visible change.

Lead time for changes is the most sensitive to its own definition. Measured from commit to production, developers keep work on a local branch until the day it will merge, and the queue time simply moves upstream where you are not looking. Measured from when work starts, it is honest but harder to instrument. The number can improve substantially while the time from "customer asked" to "customer has it" is unchanged, which is the interval the customer experiences.

Change failure rate is gamed by reclassification. An incident becomes "planned maintenance", a rollback becomes "a configuration adjustment", a hotfix within thirty minutes becomes "part of the original release". Any measure that depends on a human labelling an event will be shaped by what that label costs the labeller.

Failed deployment recovery time is gamed by closing the incident when service is nominally back and reopening nothing, or by declaring the incident later than it began. Both compress the measured window without changing what users endured.

Deployment rework rate is gamed by folding the remediation into the next scheduled release, so the follow-up work arrives as a feature commit rather than as rework. It is the hardest of the five to game convincingly, which is largely why it was added.

Reporting them without creating a league table

The unit of measurement is a delivery system — an application, a value stream, a deployment pipeline — not a person and usually not a team in isolation. Two teams' numbers are not comparable when one owns a greenfield service with an automated pipeline and the other maintains a monolith with a manual change board, so ranking them measures the estate they inherited rather than anything they control. Show each system's trend against its own past, with the distribution and not just a median.

The productive use is diagnostic. A long lead time with a low change failure rate says work is waiting somewhere — approvals, environments, review queues — and the fix is in the pipeline rather than in the people. A high change failure rate with frequent deployments says the safety net is thin: test coverage, progressive delivery, the ability to roll back. In both cases the measure points at a constraint, which is the only thing a metric is good for.

Two lines to hold in the conversation with leadership. First, these go on no individual's objectives, because the moment a number affects someone's rating the labelling incentives above become overwhelming. Second, ask what decision the dashboard is meant to support; if the answer is "so we can see which teams are underperforming", you are being asked for a ranking with a research citation attached, and it is better to say so early than to build it.

What the keys are silent about

They measure how well you deliver change, and say nothing about whether the change was worth making. A team can achieve elite figures on all five while shipping features nobody uses, and a dashboard that shows only these will quietly redefine success as delivery speed. Pair them with something about outcome — adoption, retention, the specific business result the work was funded to move — and with something about the people doing it, since burnout produces excellent short-run throughput and no sustainable capability.

Report them as a system's trend and a diagnosis; the moment they become a per-team scoreboard, you have swapped a research instrument for a labelling contest.