NeuralWired

Google’s DORA Metrics Are Failing Engineering Teams

Engineering Metrics

Your Team Ships 40 Times a Day. Goals Still Miss.

Deployment frequency is up. Lead time is down. Every dashboard is green. And your VP of Engineering still can’t explain why the roadmap slipped a quarter behind. If that sounds familiar, you’re not measuring the wrong things badly. You’re measuring the wrong things well.

DORA metrics, the deployment frequency, lead time, change failure rate, and recovery time framework born out of Google Cloud’s DevOps Research and Assessment program, have become the default scoreboard for engineering performance. In 2024, only 19% of teams surveyed hit “elite” status on that scoreboard. Yet DORA’s own research team has publicly warned against using these numbers to judge team performance at all. So what are engineering leaders supposed to trust instead?

In this article:

What DORA Metrics Actually Measure

DORA started as a research program, not a dashboard. Dr. Nicole Forsgren, Jez Humble, and Gene Kim built it, and their 2018 book Accelerate introduced what became known as the Four Keys: deployment frequency, lead time for changes, change failure rate, and time to restore service. Google Cloud has run the program since acquiring the founding team’s research in 2018.

In 2024, DORA added a fifth metric: rework rate, which tracks how many deployments are actually emergency fixes for problems the last deployment caused. That addition alone tells you something. The original four measure how fast you move. Rework rate exists because moving fast and moving in circles started to look identical on the old dashboard.

Quick definition: An “elite” DORA performer deploys on demand, has a lead time under one day, keeps change failure rate near 5%, and restores service in under an hour. In 2024, roughly one in five surveyed teams qualified. Source: DORA 2024 State of DevOps Report

The “Elite Performer” Number Nobody Questions

Here’s the stat that gets stapled to every engineering leadership deck: elite performers deploy 182 times more frequently than low performers, and they restore service 2,293 times faster. Those numbers are real, pulled from a survey of more than 39,000 professionals for the 2024 State of DevOps Report. They’re also the least useful numbers in the report if you’re trying to explain a missed quarter.

Look at what happened to the middle of the distribution instead. Between 2023 and 2024, the share of low-performing teams grew from 17% to 25%. The share of high performers shrank from 31% to 22%. The industry didn’t get better at DevOps last year. It got worse, on average, while adopting more DevOps tooling than ever.

Metric20232024
Low-performing teams17%25%
High-performing teams31%22%
Elite-performing teamsnot tracked19%
That’s the gap the headline is pointing at. A team can hit every DORA benchmark and still be part of a shrinking pool of teams whose actual delivery outcomes are stagnant or backsliding.

Why Speed and Goals Keep Diverging

DORA’s own research team saw this coming. In October 2023, according to reporting cited on DORA’s Wikipedia entry, the team explicitly warned against using the Four Keys to evaluate individual teams’ performance. That’s an unusual thing for a research program to say about its own flagship metrics. It’s also exactly what you’d expect once a research tool turns into a KPI baked into Jira, GitLab, and every engineering-analytics dashboard on the market.

This is Goodhart’s Law showing up in production code. Once deployment frequency becomes the target, it stops measuring what it used to measure. Teams under pressure to hit a number will split pull requests into smaller, more frequent deploys without changing what actually ships. They’ll quietly under-report incidents to protect their change failure rate. None of that improves the product. All of it improves the chart.

Teams pressured to raise their deployment rate by a fixed percentage can hit that target simply by shipping smaller changes more often, without touching the bugs or incidents that actually determine whether users are happy. Laura Tacho, CTO, DX · getdx.com/podcast
DORA even flags this tension inside its own 2024 data. Teams that adopted internal developer platforms saw individual productivity and overall organizational performance improve, but the report also found decreased change stability and throughput as a side effect. Speed up one lever, and another one moves without anyone touching it.

What AI Adoption Did to the Data

If DORA metrics were shaky before, AI made the cracks visible. The 2024 report found that a 25% increase in AI adoption correlated with a 1.5% decrease in throughput and a 7.2% decrease in stability, DORA’s own team flagged this as correlational rather than causal, but the direction is notable.

By the time the 2025 State of AI-assisted Software Development Report came out, AI use had reached 90% of surveyed professionals, with more than 80% reporting productivity gains. But 30% still said they had little or no trust in the code AI generated for them. The report’s core finding, drawn from nearly 5,000 professionals and over 100 hours of qualitative interviews, was blunt: AI doesn’t fix a broken team. It amplifies whatever was already there. Strong teams get stronger. Struggling teams get their existing dysfunction on fast-forward.

That’s the mechanism behind the headline. A team with process debt that starts using AI coding tools doesn’t quietly improve. It ships more, faster, with the same underlying gaps, and those gaps show up downstream as missed goals rather than upstream as slow commits.

The Case Against DORA Entirely

Not everyone thinks DORA metrics deserve the reverence they get. Dr. Junade Ali, a software engineering manager who ran independent polling with Survation and J.L. Partners, published a pointed critique on HackerNoon in January 2024 arguing the entire premise is backwards.

His research found that both software engineers and the general public rank data security, data accuracy, and bug prevention well above deployment speed when asked what matters in software delivery. That directly contradicts what the Four Keys are built to optimize for. Ali also points out that DORA’s team doesn’t publish raw survey data, unlike polling organizations bound by disclosure rules such as the British Polling Council, which require full data tables within two working days of publication.

It’s hard to find a hypothesis connecting the Four Key Metrics to the outcomes that developers and the public actually say they care about most. Dr. Junade Ali, Software Engineering Manager · HackerNoon, January 2024
His research also found something worth sitting with: 98% of UK business decision-makers and 96% of their US counterparts agreed that the actual goal of an engineering team is delivering high-quality software on time, not shipping the highest possible number of deploys. Nobody polled thinks speed is the goal. Yet speed is what gets measured, reported, and rewarded.

What Replaces DORA in 2026

The clearest answer to “what should we measure instead” so far is DX Core 4, a framework announced in December 2024 by DX co-founder and CEO Abi Noda and DX CTO Laura Tacho, built with input from DORA co-creator Dr. Nicole Forsgren and Dr. Margaret-Anne Storey. It’s worth being upfront here: DX sells the platform that implements this framework, so its published outcomes come from the vendor itself, not an independent auditor.

With that disclosed, the numbers are still notable. Tested across more than 300 organizations, DX Core 4 has been associated with 3 to 12% increases in engineering efficiency and a 14% increase in R&D time spent on new feature development. The framework’s structure is the real change: it pairs DORA’s speed metrics with effectiveness, quality, and business impact measures, so a team can’t improve one number by quietly breaking another.

The big question is, what should we actually be measuring? DORA’s throughput numbers alone were never built to capture developer experience or business impact. Abi Noda, Co-founder & CEO, DX · LeadDev, December 2024

The market is already voting with its budget

Platform engineering investment backs this shift up. Gartner projections cited in industry compilations put platform engineering team adoption at 80% of large software organizations by 2026, up from 45% in 2022 (worth verifying directly against a current Gartner release before you cite the figure yourself). The broader DevOps software market itself is priced anywhere from roughly $15 billion to nearly $19 billion for 2026 depending on which research firm you ask, a wide enough range that any single number should be treated as directional, not precise.

Our read: this signals engineering leadership is done treating DORA as a finished answer. The direction for 2026 is DORA plus a counterbalancing quality or business-impact metric, not DORA replaced outright.

Frequently Asked Questions

What are the DORA metrics?

DORA metrics are five software delivery measurements, deployment frequency, lead time for changes, change failure rate, failed deployment recovery time, and rework rate (added in 2024), developed by Google Cloud’s DORA research program to evaluate delivery speed and stability.

What is an elite DORA performer?

In DORA’s 2024 report, elite performers deploy on demand, have lead times under a day, keep change failure rates near 5%, and recover from failures in under an hour. Only about 19% of surveyed teams qualified as elite that year.

Are DORA metrics enough to measure engineering success?

No. DORA’s own team warned in October 2023 against using the Four Keys to evaluate individual teams. Newer frameworks like DX Core 4 pair DORA with developer experience and business impact metrics to avoid a narrow, gameable view of performance.

What is Goodhart’s Law and how does it apply to DORA metrics?

Goodhart’s Law holds that once a measure becomes a target, it stops being a good measure. Applied to DORA, teams pressured to hit deployment-frequency targets can split pull requests artificially or under-report incidents to protect their numbers, without improving actual delivery outcomes.

What is DX Core 4?

DX Core 4 is a 2024 framework combining DORA, SPACE, and DevEx research into four dimensions: speed, effectiveness, quality, and business impact. It was built by DX’s Abi Noda and Laura Tacho with input from DORA co-creator Dr. Nicole Forsgren.

Where This Goes Next

Here’s what the data actually tells you, once you stop reading the headline numbers in isolation: DORA metrics were never designed to be a scoreboard for individual teams, and the program’s own researchers said so in writing back in 2023. What they measure well is delivery speed and stability at an aggregate level. What they can’t tell you is whether that speed is producing anything your business actually wanted.

Over the next 6 to 18 months, expect three things to play out. First, more engineering orgs will pair DORA with a second framework, DX Core 4 or something built in-house, rather than reporting DORA numbers alone in board decks. Second, AI’s split effect (individual productivity up, organizational stability shaky) will keep showing up in DORA’s own annual reports until teams fix underlying process debt instead of layering AI on top of it. Third, watch for tooling vendors to start marketing “beyond DORA” dashboards as a category, the same way “shift-left security” became a category once perimeter security stopped being enough on its own.

Three things worth watching yourself over the next few quarters: whether your org’s change failure rate moves in the same direction as your deployment frequency, whether anyone above you is asking about rework rate at all, and whether a platform engineering investment is quietly trading stability for speed without anyone naming the tradeoff out loud.

Want the next report before your competitors do? Subscribe to The Neural Loop at neuralwired.com/newsletter.

Written by

Team_Neuralwired

in

,

More posts