DORA Metrics Explained: What Engineering Managers Actually Need to Know
2026-07-05 · 8 min read · GitHub & Metrics
Most engineering metrics measure the wrong things. Lines of code, story points, PR count — they tell you how busy people are, not how well the team delivers value. DORA metrics are different. They came out of six years of research across thousands of engineering teams, and they measure what actually matters: how fast you deliver, how stable that delivery is, and how well you recover when things go wrong.
Here's what every engineering manager needs to understand about them.
What DORA Actually Stands For
DORA is the DevOps Research and Assessment programme, run by Google. Their annual State of DevOps report has tracked what separates elite engineering teams from average ones since 2014. The four metrics they settled on aren't arbitrary — they're the ones that most reliably predict whether a team delivers software that works and keeps working.
The four metrics:
- Deployment Frequency — how often you deploy to production
- Lead Time for Changes — how long from code commit to code in production
- Change Failure Rate — what percentage of deployments cause a production incident
- Mean Time to Recover (MTTR) — how long to restore service after a failure
Together, these give you a picture of both speed (frequency, lead time) and stability (failure rate, recovery time). The insight that makes DORA valuable is this: elite teams aren't just fast or stable — they're both. Speed and stability correlate, not trade off.
What Each Metric Tells You
Deployment Frequency is the clearest signal of team confidence and pipeline health. Teams that deploy multiple times per day have usually solved the hard problems: automated testing, feature flags, fast review cycles, reliable CI. Teams that deploy monthly are usually managing risk through infrequency, which is the riskiest approach of all.
If your team deploys infrequently, the question isn't "how do we deploy more" — it's "what makes deploying feel risky?" The answer is usually inadequate test coverage, a painful manual process, or a culture of blame when things break.
Lead Time for Changes measures the lag between a developer writing code and a user seeing it. Long lead times accumulate in two places: waiting (PR queue, review time, approval gates) and rework (code that needs multiple rounds of fixes). If you're tracking PR cycle time separately, lead time is the upstream version of that number.
A high lead time usually means one of: too much work in flight, PRs sitting unreviewed, or a release process with too many manual steps.
Change Failure Rate answers the question "how often do we break things?" Elite teams sit between 0–15%. If you're above 30%, your delivery speed is largely an illusion — you're shipping fast but fixing frequently. High failure rates usually point to insufficient automated testing, deploying too much at once, or a testing environment that doesn't match production.
Mean Time to Recover is often the most neglected metric but arguably the most important. Every system fails. What separates elite teams isn't that they have zero incidents — it's that they recover in minutes, not hours or days. MTTR measures your observability, your on-call practice, and your runbook discipline.
The Four Tiers
The DORA research bucketed teams into four performance levels:
| Tier | Deploy Freq | Lead Time | Failure Rate | MTTR |
|---|---|---|---|---|
| Elite | Multiple/day | < 1 hour | 0–15% | < 1 hour |
| High | 1/day–1/week | 1 day–1 week | 16–30% | < 1 day |
| Medium | 1/week–1/month | 1 week–1 month | 16–30% | 1–7 days |
| Low | < 1/month | 1–6 months | 16–30% | > 6 months |
Most product teams at growth-stage companies are in the Medium tier. That's fine as a starting point. The goal is directional improvement, not instant elite status.
What DORA Metrics Don't Measure
DORA metrics tell you nothing about whether you're building the right things. A team can score elite on all four metrics and still be shipping features nobody uses. They also don't measure code quality, technical debt, or team satisfaction.
They also don't account for complexity. Deploying a marketing site multiple times per day is very different from deploying safety-critical backend infrastructure. Context matters.
Use DORA to understand your delivery system. Use product metrics to understand whether the delivery system is pointed in the right direction.
How to Start Tracking Them
You don't need elaborate tooling to start. A reasonable starting point:
- Deployment Frequency: count deployments to production per week from your CI logs or deployment platform
- Lead Time: median time from first commit on a branch to merge, available in most PR tools
- Change Failure Rate: incidents caused by deployments / total deployments, tracked in your incident log
- MTTR: incident start to resolution time, from PagerDuty, Opsgenie, or a simple log
The number you measure first is less important than establishing a baseline. You can't improve what you don't track.
The Manager's Role
Your job as an EM isn't to move DORA numbers — it's to remove the obstacles that keep your team from moving them. That means:
- Running blameless postmortems when failure rate is high
- Reviewing PR review latency when lead time is long
- Investing in test infrastructure when deployment feels risky
- Building clear on-call runbooks when MTTR is high
DORA metrics are a diagnostic, not a target. When you share them with your team, frame them as questions: "Our lead time has been creeping up — what's getting in the way?" Not: "We need to hit X by Q2."
Teams that treat DORA as a scorecard to game quickly learn to game it. Teams that treat it as a mirror improve their actual delivery.