The DORA Four Keys
Measure software delivery with two speed and two stability metrics that move in tandem.
- Difficulty
- Moderate
- Time to result
- ~months to results
- Steps
- 4
- Confidence
- 95%
DORA distills software delivery performance into four metrics: two for speed (lead time, deployment frequency) and two for stability (time to restore, change fail rate). The counterintuitive research finding is that speed and stability move together, not against each other — shipping smaller changes more often makes you both faster and more stable. Teams benchmark themselves against low/medium/high/Elite performers, but the real value is knowing where you are and whether you are making progress.
Origin
Developed through the DORA (DevOps Research and Assessment) research program co-founded by Nicole Forsgren with Jez Humble and Gene Kim, originating from work with Puppet's State of DevOps report (shout out to Alana Brown and Nigel Kersten). The program was acquired by Google; benchmarks are now maintained by Dr. Dustin Smith and Nathan Harvey at dora.dev.
Core principles
- 01Speed and stability move together with strong statistical significance — you don't trade one for the other.
- 02Smaller, more frequent changes have a smaller blast radius, so bugs are easier to debug and restore.
- 03Large batched changes create large blast radius, merge conflicts, and painful disentanglement when something breaks.
- 04Precision doesn't matter — general categories (less than a day vs a day-to-a-week) are enough; people can hunch it.
- 05What matters most is knowing where you are and whether you're improving, not whether you're labeled Elite.
- 06The gap is often a business decision vs a technical capability — know which one is holding you back.
How to run it
- 1
Measure your two speed metrics
Track lead time (how long from code committed to code running in production, up to about ring zero) and deployment frequency (how often you deploy code).
Pro tip Measure lead time from commit into the repo out to ring-zero production, not the final global deploy endpoint — the question is whether your deployment pipeline gives you fast, predictable feedback.
- 2
Measure your two stability metrics
Track mean time to restore (MTTR — how long to recover when something breaks) and change fail rate (the rough percentage of changes that cause an incident requiring human intervention).
- 3
Locate yourself against the benchmarks
Compare against Elite performance: deploy on demand, lead time under a day, restore under an hour, change fail rate 0-15%. The next tier (high) has lead time between a day and a week, then a week to a month, then a month to six months.
Pro tip Use the free quick check at dora.dev — it collects no name or contact info, and after placing you it names the constraints teams in your performance profile and industry typically struggle with.
- 4
Improve by shipping smaller batches more often
To get faster AND more stable, push smaller changes more frequently rather than batching up large releases behind long change-approval windows.
Watch out Forcing multi-week change-approval pauses (the old ITIL/ITSM 'two-week wait for stability' rule) actually batches up changes and creates the instability it was meant to prevent — it's an old wives' tale.
In the wild
When benchmarking, the only statistically significant difference by company type was retail, which performed better than everyone else. Forsgren surmises this is natural selection: retailers that couldn't handle on-demand bursting (Black Friday, being in the cloud) simply did not survive the retail apocalypse, so the survivors are all high performers.
→ Illustrates that the benchmarks apply across company sizes — there was no statistically significant difference between small and large companies, undercutting both 'we're too big/complex' and 'we're too small/under-resourced' excuses.
If a committed change takes three months to reach production and then breaks, the developer has to context-switch back in, re-read and re-review code from a whole quarter ago, and possibly reload an entire workspace of libraries. If the same break happens in under a day, the developer still has the mental model loaded and can fix it quickly.
→ Shows how slow lead time directly degrades developer experience, not just delivery speed.
Common mistakes
Treating the four metrics as the whole of DORA
DORA is an entire research program; the four metrics are just the best-known output. Fixating on them without the supporting capabilities (technical, architectural, cultural, lean management practices) means you measure performance without knowing how to improve it.
Assuming you must slow down to be stable
Believing you need change-approval waiting periods or fewer deploys to protect reliability is backwards — it creates large batches, big blast radius, and merge conflicts. Speed and stability are correlated, not opposed.
Is it for you?
Best for
Engineering leaders and founders who want to move faster and need an evidence-based way to benchmark delivery performance and diagnose what's holding their team back.
Not ideal for
Teams who will use the benchmarks only to feel judged rather than to identify and improve the underlying capabilities, or who need per-metric precision beyond broad categories.
From the transcript
“the speed metrics are lead time so how long does it take to get from code committed to code running in production deployment frequency how…”
“when you move faster you are more stable which means you're you're pushing smaller changes more often right so if you're pushing all the time…”
“the Elite Performance so deployment frequency you can deploy on demand lead time for changes takes less than a day time to restore is less…”
“what's most important is knowing where you are and the progress that you're making right it doesn't matter if frankly you're a high performer or…”
From the episode
How to measure and improve developer productivity
Nicole Forsgren (Microsoft Research, GitHub, Google)