Four numbers that describe how a change reaches production.

What the four keys measure

Deployment frequency is a proxy for batch size: how much risk is bundled into each release. Lead time for changes asks how long a change sits still, and most of it is waiting, not coding, which is why it usually points at something you can fix. Change failure rate is the counterweight that stops the first two becoming a speed contest. And time to restore service is the one outsiders find least intuitive: teams that recover quickly outperform teams that fail rarely, because optimising for never breaking produces caution, and caution is expensive in ways no dashboard shows.

Read together they describe a system that can move quickly and absorb being wrong. Read alone, each has an obvious way to cheat it.

Instrumenting them from what you already have

You need less than most tooling implies. Deployment frequency is one event per successful production deploy. Lead time is the commit timestamps on a change and the deploy that shipped it. The fiddly part is knowing which deploy carried which merge, which is why it is worth attributing a deploy to the change it released rather than to the machine account that triggered it.

Change failure rate and time to restore need one decision and two fields: what counts as a failure, and when it started and stopped. The decision is the actual work. Write it down, because a definition that lives in somebody’s head will drift.

The three ways teams break them

Measuring them per person. Deployment frequency per engineer is not a DORA metric; it measures who happens to work on the service with the least release friction. The unit is a delivery system: a team, a service, a value stream.

Benchmarking against other companies. The published bands aggregate across regulated and unregulated, greenfield and thirty-year-old. The comparison that carries information is your own team against itself last quarter.

Instrumenting only the easy two. Frequency and lead time come nearly free; failure rate and restore time need a definition. Half of DORA is not a smaller DORA. It is a velocity target with the safety metrics removed.

What the four keys will not tell you

They describe the pipe, not what goes through it. A team can be elite on all four while shipping features nobody uses, and the numbers will look magnificent the entire time. They say nothing about whether the architecture is accumulating debt, whether the on-call rota is burning people out, or whether the roadmap is any good.

That is not a criticism. A thermometer is not a poor tool for failing to be an X-ray. But it is why the four keys belong beside qualitative signals rather than replacing them. The teams that get the most out of them pair the numbers with a monthly conversation about what the numbers do not explain, and treat a surprising figure as a question rather than a verdict.

A reasonable rollout

1. Instrument deployment frequency and lead time first, per service. They are nearly free and they establish the habit.
2. Write down what counts as a change failure before you measure one. Circulate it, argue about it once, then leave it alone. A definition that changes every six weeks makes every comparison meaningless.
3. Report all four together, per team, per month. Never per person; that is the change that quietly ends the programme.
4. Compare each team to its own previous quarter. Treat any external benchmark as orientation, never as a target.
5. Show the team its own numbers at the same time you show anyone else. They will tell you when the attribution is wrong, and at first it will be.

Then leave it alone long enough to mean something. The most common failure after instrumentation is not a wrong metric. It is changing the definition so often that no two quarters can be compared.

Where this fits

Gamify Work is not a DORA dashboard, and if that is all you want there are narrower tools. What it does is take the same events, such as merges, deploys, incidents, or whatever else you send, and let you rank and reward on them at the team level, with individual visibility as a decision rather than a default. If you already instrument the four keys, sending them here costs one webhook.