DORA Metrics for Engineering Managers: A Practical Guide (2026)

TL;DR: DORA metrics (deployment frequency, lead time for changes, change failure rate, MTTR, and the new documentation quality metric) are the gold standard for measuring software delivery performance. But they measure delivery, not team health. Engineering managers need DORA plus review quality, rework rate, and AI adoption to get the full picture.

Every few years, engineering gets a new framework that promises to finally answer “how is our team doing?” Most of them fade. DORA didn’t. Ten years in, DORA metrics are still the closest thing we have to an objective standard for software delivery performance — and in 2025, they added a fifth metric that most people haven’t caught up on yet.

But here’s the problem: most engineering managers either treat DORA as gospel (it’s not) or ignore it entirely because it feels too academic (it’s not that either). The truth is somewhere in the middle: DORA gives you a strong foundation, and you need to build on it.

What do DORA metrics actually measure?

DORA measures software delivery performance. Not developer productivity. Not team happiness. Not code quality. Delivery performance — how fast and how safely your team gets code from commit to production.

The framework comes from the DORA team at Google (originally Puppet Labs / DevOps Research and Assessment), backed by the largest longitudinal study of software delivery ever conducted. Over 39,000 professionals surveyed across 10+ years. This isn’t someone’s blog post opinion. It’s peer-reviewed research.

The original four metrics launched in 2014. In 2025, the DORA team added a fifth: documentation quality. Here’s the full set:

Deployment Frequency — How often does your team deploy to production?
Lead Time for Changes — How long from commit to running in production?
Change Failure Rate — What percentage of deployments cause a failure?
Mean Time to Recovery (MTTR) — How quickly do you recover from failures?
Documentation Quality — How reliable and up-to-date is your technical documentation?

The first two measure speed. The next two measure stability. The fifth measures sustainability. The research shows that elite teams score high on all five — speed and stability aren’t tradeoffs; they reinforce each other.

Why did DORA become the industry standard?

Because it’s backed by data, not opinions. Most engineering metrics frameworks are someone’s best guess. DORA is the output of statistically rigorous research published in peer-reviewed venues and summarized in the Accelerate book (Forsgren, Humble, Kim).

The key insight that made DORA stick: high-performing teams deploy more frequently and have fewer failures. This destroyed the old assumption that you had to choose between moving fast and being safe. It gave engineering leaders ammunition to push for CI/CD, trunk-based development, and smaller batch sizes.

It also gave executives a shared language. When your VP of Engineering says “our deployment frequency is weekly and our lead time is 3 days,” that means the same thing at every company. Try saying that about story points.

What are the 5 DORA metrics and their benchmarks?

Here’s where it gets practical. The 2025 State of DevOps Report provides clear benchmarks:

Deployment Frequency

Elite: On-demand (multiple deploys per day)
High: Between once per day and once per week
Medium: Between once per week and once per month
Low: Less than once per month

If you’re deploying less than weekly, something is blocking you — usually fear of breakage, manual QA gates, or monolithic architecture. Fix the pipeline before anything else.

Lead Time for Changes

Elite: Less than one hour
High: Between one day and one week
Medium: Between one week and one month
Low: More than one month

This is commit-to-production time. It includes CI, code review, staging, and deployment. Most teams I’ve seen are bottlenecked on code review — PRs sitting in queue for days.

Change Failure Rate

Elite: 0–5%
High: 5–10%
Medium: 10–15%
Low: 15%+

A failure is any deployment that requires a hotfix, rollback, or causes a degradation. Below 5% is world-class. Above 15% means your testing and review processes need serious work.

Mean Time to Recovery (MTTR)

Elite: Less than one hour
High: Less than one day
Medium: Between one day and one week
Low: More than one week

MTTR is your resilience metric. Elite teams recover in under an hour because they have automated rollbacks, feature flags, and solid observability. If your MTTR is measured in days, invest in incident response tooling before anything else.

Documentation Quality (New in 2025)

Elite: Documentation is consistently up-to-date, findable, and reliable
High: Most documentation is current and useful
Medium: Documentation exists but is often outdated
Low: Documentation is sparse or unreliable

This is the newest addition and the hardest to measure quantitatively. The DORA team found that documentation quality is a statistically significant predictor of delivery performance — teams with reliable docs onboard faster, resolve incidents quicker, and make fewer mistakes.

Why isn’t DORA enough for engineering managers?

Because DORA measures the pipeline, not the people. It tells you how fast code gets to production and how often it breaks. It doesn’t tell you:

Whether code reviews are actually catching bugs or just rubber-stamping
How much rework is happening after merge
Whether your team is adopting AI tools effectively
Whether one person is bottlenecking all reviews
Whether junior engineers are getting meaningful feedback

DORA is an infrastructure metric at its core. It’s phenomenal for answering “is our delivery pipeline healthy?” It’s insufficient for answering “is my engineering team healthy?”

MergeScout is an AI-powered engineering metrics dashboard that watches your GitHub repos and delivers executive briefings in seconds. We built it because DORA alone left too many questions unanswered for the engineering managers we talked to. They needed delivery metrics and team health metrics in one place.

What complementary metrics fill the gaps DORA leaves?

Four metrics that pair perfectly with DORA:

Review rounds — the number of review cycles before a PR is approved. DORA measures lead time but doesn’t break down where the time is spent. Review rounds tell you if the bottleneck is in code review. Two rounds is healthy. Five rounds means something is off — unclear requirements, misaligned expectations, or a reviewer who can’t let go of style preferences.

Rework rate — percentage of code changed within 14 days of merging. DORA’s change failure rate captures production failures, but rework rate captures the bugs and oversights that don’t make it to production but still cost time. High rework with low change failure rate means your QA process is catching things that review should have caught.

Comment quality — are code reviews substantive? A team can have fast lead times and low review rounds while doing terrible reviews. Comment quality is the signal that tells you whether the review process is actually working or just going through the motions. Check out our deeper dive on metrics that matter for more on this.

AI adoption rate — what percentage of PRs show signals of AI-assisted development? In 2026, this matters because AI tools fundamentally change cycle time and rework patterns. You need to know if your team is adopting them and what the impact looks like.

Together, DORA plus these four metrics give you a complete picture: delivery speed, delivery stability, review effectiveness, code quality, and tooling adoption.

How do you set up a DORA-compatible dashboard in 60 seconds?

Most DORA dashboards require you to instrument your CI/CD pipeline, tag deployments, and configure failure detection. That’s weeks of setup for a team that just wants to see the numbers.

Here’s the faster path with MergeScout:

Connect your GitHub repos — OAuth takes 30 seconds
MergeScout syncs your PR and deployment data — automatic, no configuration
View your dashboard — cycle time, review rounds, rework rate, comment quality, and AI adoption are computed instantly

MergeScout approximates deployment frequency and lead time from your merge-to-main patterns and release tags. It’s not a full DORA implementation (you’d need CI/CD integration for exact change failure rate and MTTR), but it gives you lead time and deployment frequency alongside the team health metrics that DORA doesn’t cover.

For most teams under 50 engineers, this is more than enough. You get 80% of DORA’s value plus the team-level metrics that DORA misses, all without a DevOps engineering project to set it up.

Try it free — beta access is open.

How should you present DORA metrics to leadership?

Don’t dump all five metrics on a slide and call it a day. Executives care about two things: are we shipping fast, and is it safe?

Frame it as a 2x2:

Speed: Deployment frequency + lead time
Stability: Change failure rate + MTTR
Sustainability: Documentation quality

Then add one line on team health: “Review quality is strong, rework rate is low, AI adoption is at X%.” That’s your full story in 30 seconds.

If a metric is red, come with the why and the fix, not just the number. “Lead time increased from 2 days to 5 days because we had 3 PRs stuck in review for over a week. We’re addressing it by adding a second reviewer rotation.” That’s what leadership wants to hear.

Frequently Asked Questions

What are the 5 DORA metrics in 2026?

The five DORA metrics are deployment frequency, lead time for changes, change failure rate, mean time to recovery (MTTR), and documentation quality. The fifth metric — documentation quality — was added by the DORA team in 2025 based on research showing it significantly predicts delivery performance.

How do DORA metrics differ from developer productivity metrics?

DORA measures software delivery pipeline performance — how fast and safely code gets to production. Developer productivity metrics (like cycle time per developer, review rounds, and rework rate) measure how effectively individual engineers and teams work within that pipeline. You need both for a complete picture.

Can small teams benefit from DORA metrics?

Yes. DORA metrics are even more valuable for small teams because every bottleneck has an outsized impact. A team of 8 engineers with a 5-day lead time has a very different problem than a team of 200 with the same number. Start with deployment frequency and lead time — they’re the easiest to measure and the most actionable.

What is a good change failure rate?

Elite teams maintain a change failure rate below 5%. Between 5-10% is considered high-performing. Above 15% indicates significant issues with testing, review, or deployment practices. Focus on automated testing, feature flags, and thorough code review to bring this number down.

How do I track DORA metrics without instrumenting my CI/CD pipeline?

Tools like MergeScout can approximate deployment frequency and lead time from your GitHub merge patterns and release tags without requiring CI/CD instrumentation. This gives you a fast starting point. For exact change failure rate and MTTR, you’ll eventually want to connect your deployment and incident tracking systems.