DORA Metrics Are Useful. Most Teams Misuse Them.
A practical take on DORA metrics, what the four keys really measure, the 2025 changes, and how to use them without gaming yourself.
By Dipankar Sinha
DORA metrics are the closest thing our industry has to an honest, research-backed answer to "is this engineering team any good?" They come out of more than a decade of study across a hundred thousand-plus professionals, which is why they carry weight in a room where most productivity metrics are just someone's opinion dressed as data.
And that credibility is exactly why they get misused. The moment a metric becomes a scoreboard, people start optimizing the number instead of the thing the number was supposed to represent. So let me lay out what the four keys actually measure, what changed in the 2025 research, and how to use them without quietly fooling yourself.
The four keys, in plain language
There are two things you care about with software delivery: how fast you ship, and how safely. DORA splits each into two measurable pieces.
Speed:
- Deployment frequency. How often you ship to production. High-performing teams deploy on demand, multiple times a day. Struggling ones ship every few weeks in a tense, ceremonial release.
- Lead time for changes. How long from a commit to that commit running in production. It measures the friction of your pipeline, not how fast people type.
Stability:
- Change failure rate. What percentage of your deployments cause a problem that needs a fix. Not bugs in general. Deployments that break things.
- Failed deployment recovery time. When a deployment does break something, how fast you're back to healthy. (This is the metric formerly known as MTTR; the 2024/2025 research renamed it to be more precise.)
The genuinely important insight buried in all that research: speed and stability are not a trade-off. The best teams are better at both, at the same time. The idea that you have to choose between shipping fast and shipping safely is one of the most expensive myths in engineering, and the data has been quietly demolishing it for years. I put the current benchmark bands into a DORA reference card if you want to see where your team sits.
What changed in 2025 (and why it matters)
If you learned DORA a few years ago, two things are worth updating.
First, the famous Elite / High / Medium / Low performance tiers (the ones everyone screenshotted to argue their team was "elite") were dropped in the 2025 report. In their place is a set of team archetypes, because the researchers found that a single ranking flattened teams that were strong in different ways. A team can be a rapid shipper and a fragile one at the same time, and one label hid that.
Second, they added a fifth metric: rework rate. Roughly, it's how much of your work is unplanned fixing of things you thought were done. It's a quiet but brutal signal, because a team can look fast and stable while secretly drowning in redo.
The other headline from that research: nearly everyone is now using AI in their daily workflow, and (this surprised people) heavier AI adoption correlated with more delivery instability, not less. Faster code generation with the same review and testing discipline just means you ship your mistakes faster. That's not an argument against AI. It's an argument that the surrounding system has to keep up with the new speed.
How teams fool themselves with these numbers
Here's where I earn my keep, because I've watched every one of these happen.
Gaming deployment frequency. Tell a team their deploy count is being watched, and suddenly one deploy becomes five, split artificially. The number goes up. Nothing improved. You measured theater.
Hiding change failure rate. If failures are punished, failures stop getting reported. Your dashboard turns green not because things got better but because people got scared. A suspiciously perfect change failure rate is usually a culture problem, not an engineering triumph.
Treating benchmarks as targets. The bands from the research are descriptive: this is what teams out there look like. They are not a target you should force your team to hit regardless of context. A team maintaining a stable, mature product has different healthy numbers than one racing to product-market fit. Copying someone else's number is how you optimize for the wrong thing.
Watching the metrics instead of the trend. The absolute value matters far less than the direction. A team moving from monthly to weekly deploys is winning, even if "weekly" isn't "elite." Where you're heading beats where you are.
How to actually use them
Use DORA as a mirror, not a scoreboard. Measure your own team against its own past, privately, and ask "what's the friction?" when a number is ugly. The metrics are diagnostic, they tell you where to go look, not who to blame.
Pair them with something the four keys don't capture: how the team actually feels. The same researchers behind DORA built the SPACE framework precisely because delivery speed says nothing about burnout, and a team can post beautiful numbers for two quarters right before half of it quits. A fast, stable, miserable team is a countdown, not a success.
Get that balance right and DORA earns its reputation. It stops being a stick and becomes what it was designed to be: an honest question about whether your system for building software is getting better or worse.
Want an outside read on your delivery health, the numbers and what's actually driving them? That's a core part of the technology audits I run. Get in touch.