DORA Metrics for Leaders: Five Delivery Measures and Their Pitfalls

If your organization builds or runs software, someone has probably shown you the DORA metrics, often as a dashboard ranking teams from best to worst. The metrics are useful. The ranking is the part DORA's own guidance warns against.

DORA is a research program run by Google Cloud that has studied software delivery since 2014. This guide explains what its software delivery metrics measure today, what DORA says they are and are not good for, and how leaders at different levels can use them without turning them into targets that get gamed.

What DORA measures now

The metrics have changed over time. DORA's history of its metrics explains that the original model used four measures, often called the four keys. In 2023, "mean time to recover" was renamed and redefined as failed deployment recovery time, to focus on recovering from failures caused by a change rather than from external events such as a data center outage. In 2024, DORA added a fifth metric, deployment rework rate.

DORA's current guide groups the five metrics into two factors.

Throughput, or how many changes can move through the system over a period of time:

• Change lead time: the time it takes for a change to go from committed to version control to deployed in production.
• Deployment frequency: the number of deployments over a given period, or the time between deployments.
• Failed deployment recovery time: the time it takes to recover from a deployment that fails and requires immediate intervention.

Instability, or how well deployments go:

• Change fail rate: the ratio of deployments that require immediate intervention following a deployment, such as a rollback or a hotfix.
• Deployment rework rate: the ratio of deployments that are unplanned but happen as a result of an incident in production.

What the research does and does not claim

DORA says its research has found that these metrics predict better organizational performance and well-being for team members, and that speed and stability are not trade-offs: for most teams the metrics are correlated, with top performers doing well across all five. DORA describes the metrics as leading indicators for organizational performance and employee well-being, and lagging indicators for development and delivery practices.

Notice what that does not say. It does not say a higher deployment count is itself the goal, or that the metrics measure individuals. DORA's guide for business leaders says plainly that software delivery performance "is not an individual measure" and can only be achieved by teams.

Measure one application at a time

The single most important rule for leaders is about scope. DORA's guide says the metrics are best suited to measuring one application or service at a time, and that context matters. It cautions that blending metrics across multiple teams or entire organizations "can be problematic" because contexts differ.

DORA's guide for business leaders goes further for directors: avoid "reductive aggregation across teams or comparison across different contexts," and focus instead on comparing the same application and team over time. A mobile app and a mainframe system can both improve; comparing one to the other tells you very little.

For example, imagine a hypothetical insurer with a customer website deployed daily and a claims system deployed quarterly. A combined average would describe neither, and ranking the teams would mostly reward the one with the easier architecture.

The pitfalls DORA warns about

DORA's guide lists common pitfalls. Leaders are responsible for most of them:

• Setting metrics as a goal. DORA cites Goodhart's law and warns that mandates like "Every application must deploy multiple times per day by year's end" invite gaming.
• Having one metric to rule them all. Use several metrics, including some with healthy tension between them.
• Using industry as a shield, such as claiming regulation prevents any change.
• Making disparate comparisons between very different applications.
• Having siloed ownership. DORA recommends sharing all five metrics across development, operations and release teams.
• Competing against other teams or organizations instead of improving over time.
• Focusing on measurement at the expense of improvement, such as building costly integrations before having conversations.

What each level of leadership should do with them

DORA's guide for business leaders suggests different uses at different levels.

Software delivery managers can use the metrics with their teams to find improvement opportunities, drawing on DORA's catalog of capabilities, and should look for causes in the system before focusing on individuals. DORA notes, for example, that one person's commit pace may be held back by slow code reviews rather than a lack of skill.

Directors can watch trends for an application or product line, encourage teams to experiment with capabilities, and avoid cross-team aggregation.

Executives should measure software "against its purpose." If a system was built to reduce response times, measure response times; if it is a product, track its profitability. The same guide suggests that continuous improvement is "an ideal metric for a C-suite leader's OKR."

The U.S. Government Accountability Office's Agile Assessment Guide (GAO-24-105506) reaches a compatible conclusion from a different direction. It warns against optimizing a single metric at the expense of others, and its examples of team-level metrics include the time required to restore service after an outage alongside customer and user satisfaction.

A practical starting loop

DORA's guide recommends gathering the cross-functional team responsible for an application and walking through a simple loop:

1. Set a baseline using the DORA Quick Check.
2. Talk about friction points in the delivery process, perhaps by mapping it.
3. Commit as a team to improving the most significant constraint.
4. Turn that commitment into a plan, possibly with more specific leading indicators such as how long code reviews take.
5. Do the work, then check progress with the Quick Check, conversations and retrospectives.
6. Repeat.

DORA names reducing the batch size of changes as a common way to improve all five metrics, because smaller changes move through delivery more easily and are easier to recover from. According to DORA's FAQ, the Quick Check reports scores on a 10-point scale that can be compared with benchmarks from DORA's 2025 research; treat those benchmarks as context for a conversation, not a target.

Finally, remember that delivery metrics are one lens. DORA's own article on measurement frameworks describes using its delivery metrics alongside frameworks focused on developer experience or product excellence, depending on what decisions you need to make.

Key takeaways

• DORA now uses five software delivery metrics, grouped into throughput and instability.
• Apply them to one application or service at a time and compare it with itself over time.
• Do not rank teams, aggregate across contexts or set the metrics as mandated targets.
• Managers improve the system, directors watch trends and encourage experiments, executives measure software against its purpose.
• Start with a baseline, a conversation about friction and one improvement to the biggest constraint.

Sources

• Nathen Harvey for DORA, DORA's software delivery performance metrics (updated January 5, 2026)
• Nathen Harvey for DORA, A history of DORA's software delivery metrics (January 2, 2026)
• Steve Fenton, Mark Kropf and Denali Lumma for DORA, How to empower software delivery teams as a business leader (updated April 19, 2024)
• DORA, Frequently Asked Questions (updated October 6, 2025)
• DORA, Choosing measurement frameworks to fit your organizational goals (August 6, 2025)
• U.S. Government Accountability Office, Agile Assessment Guide: Best Practices for Adoption and Implementation, GAO-24-105506 (reissued with revisions December 15, 2023)