Short answer
DORA metrics are the industry-standard way to measure software delivery: how fast changes reach production and how often they break it. DORA now defines five metrics, three for throughput and two for instability. Track them per service, review trends rather than targets, and never use them to rank teams.
- 5 - software delivery metrics DORA now defines (the “four keys” grew to five)
- 3 - throughput metrics: lead time, deployment frequency, recovery time
- 2 - instability metrics: change fail rate and rework rate
- 30 days - enough to get a first, honest baseline for one product line
DORA metrics tell a CTO whether the engineering organisation can ship change quickly and safely. They are five measures defined by Google Cloud’s DORA research programme: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. Together they show speed and stability on one page, which is why boards and engineering leaders increasingly use them.
The five DORA metrics in plain English
MetricWhat it measuresQuestion it answers for leadersChange lead timeTime from a change in version control to it running in productionHow long does an idea wait before customers can use it?Deployment frequencyHow often you deploy, or the time between deploymentsCan we release small changes whenever we need to?Failed deployment recovery timeTime to recover from a deployment that needs immediate interventionWhen a release breaks something, how quickly are we back?Change fail rateShare of deployments needing a rollback, hotfix or other immediate fixHow often does shipping hurt customers?Deployment rework rateShare of deployments that are unplanned and triggered by an incidentHow much of our delivery is firefighting rather than planned work?
If your dashboards still show “mean time to restore”, they are on the older definition. DORA replaced it with failed deployment recovery time, which focuses on recovering from changes you shipped rather than every outage, and added deployment rework rate to expose hidden firefighting.
Why speed and stability belong together
The core finding behind DORA is that speed and stability are not a trade-off. Teams that deploy small changes often tend to fail less and recover faster, because each change is easier to test, review and roll back. Looking at throughput without instability rewards reckless shipping; looking at instability alone rewards shipping nothing.
For a leader, this changes the conversation. Instead of asking engineering to “move faster” or “be more careful”, you can ask which constraint is holding delivery back: long reviews, manual testing, risky big-bang releases or slow incident response. It also matters more as AI coding assistants raise the volume of code, a shift we cover in the move from software development to software orchestration.
How to start measuring in 30 days
Most teams can calculate a usable first version with a script against their CI/CD and incident APIs before buying a tool. Buy software once the definitions are stable and you know which views leaders actually use.
Mistakes that turn DORA metrics into theatre
- Ranking teams against each other. Context differs: a payments team and an internal tools team should not have the same targets.
- Setting targets as goals. When a measure becomes a target, people optimise the number, for example by splitting one change into many deployments.
- Measuring individuals. DORA metrics describe systems and teams, not people. Using them in performance reviews destroys trust and data quality.
- Ignoring outcomes. Fast, stable delivery of the wrong features is still waste. Pair the metrics with product and customer measures.
- Reporting without acting. A monthly slide nobody discusses is overhead. Every review should end with one improvement to try.
For distributed teams
In teams spread across time zones, slow reviews and hand-offs usually dominate lead time. Our guide to [[building high-performance global tech teams|/blog/building-high-performance-global-tech-teams-across-time-zones/]] covers the operating model that shortens them.
What to ask your engineering leaders
Five questions for your next review
- Can you show the five DORA metrics for our most important product, using DORA’s current definitions?
- Which single constraint most limits our change lead time today, and what is the plan to remove it?
- What share of last quarter’s deployments was rework triggered by incidents?
- How quickly did we recover from our last three failed deployments, and what changed afterwards?
- How are we making sure the metrics are used to improve the system, not to judge individuals?
As AI assistants change how code is written, DORA metrics become a useful guardrail: if lead time drops but change fail rate climbs, quality controls are not keeping up. Our article on managing engineers in the age of AI coding assistants covers how to adjust reviews and policies.
Engineering leadership
Want a delivery baseline your board can trust?
We set up DORA measurement on your existing tools, agree definitions with your teams, and turn the first baseline into a 90-day improvement plan.
Sources
- DORA’s software delivery performance metrics (dora.dev)
Originally published at phpscientist.com.
Top comments (0)