DORA Metrics and Engineering Velocity: How to Measure What Actually Matters

The DORA (DevOps Research and Assessment) team at Google conducted years of research into what distinguishes high-performing software delivery organizations. Their finding: four metrics predict engineering team performance better than any other combination.

The Four Metrics

Deployment Frequency: How often does your team deploy to production? Elite performers deploy multiple times per day. Frequency is a proxy for batch size — smaller, more frequent deployments are faster and safer than large, infrequent ones.

Lead Time for Changes: The time from a code commit to that code running in production. Elite performers achieve this in less than an hour. Lead time measures the efficiency of your entire delivery pipeline.

Change Failure Rate: The percentage of deployments that cause a production incident requiring hotfix or rollback. Elite performers have rates below 5%. This measures deployment quality.

Time to Restore Service (MTTR): When a production incident occurs, how long does it take to restore service? Elite performers restore service in less than an hour. This measures incident response maturity.

Implementing Measurement

Most metrics can be derived from existing tooling: deployment frequency from your CI/CD system, lead time from git commit timestamps to deployment events, change failure rate from incident management tools correlated with deployments, MTTR from incident tracking.

Tools like LinearB, Sleuth, and Cortex automate DORA metric collection across common DevOps toolchains.

Avoiding the Goodhart’s Law Problem

“When a measure becomes a target, it ceases to be a good measure.” Treat the metrics as diagnostics, not goals. Use them to understand where constraints are, then remove the constraints.

Why Team-Level Comparison Is the Wrong Use of These Metrics

A common and damaging misapplication of DORA metrics is using them to rank or compare individual teams against each other, treating the metrics as a performance scorecard rather than a diagnostic tool for understanding systemic constraints. Different teams legitimately face different technical contexts — a team maintaining a legacy monolith with extensive manual testing requirements will show different metrics than a team building a new service with modern CI/CD from day one, and this difference reflects the technical context rather than team competence. Organizations that use DORA metrics for team comparison and ranking tend to see exactly the gaming behaviors the metrics are vulnerable to, while organizations that use the same metrics purely as a team’s own longitudinal diagnostic tool — tracking improvement over time within that team’s specific context — get genuine value from the same underlying measurement framework.

Connecting DORA Metrics to Business Outcomes

The original DORA research’s most significant finding wasn’t the four metrics themselves but their demonstrated correlation with broader organizational performance — revenue growth, market share, and customer satisfaction. Making this connection visible within an organization, rather than treating DORA metrics as a purely technical engineering concern disconnected from business outcomes, is often what secures the leadership investment needed to actually act on what the metrics reveal. Engineering leaders who can articulate how improving deployment frequency and lead time connects to faster customer value delivery and competitive responsiveness build a stronger case for investment in the underlying infrastructure and process improvements than those presenting the metrics as an isolated engineering excellence initiative.

Building the Underlying Capabilities, Not Just Measuring Them

Ultimately, DORA metrics are diagnostic outputs of underlying engineering capabilities — robust automated testing, effective trunk-based development practices, mature monitoring and observability, and psychological safety enabling teams to deploy frequently without fear of blame for resulting incidents. Organizations that focus primarily on moving the metrics directly, without addressing these underlying capabilities, tend to find the metrics improve briefly through superficial changes before reverting, while organizations that invest in the underlying capabilities see the metrics improve as a natural consequence, connecting to the broader platform engineering investment that many organizations make specifically to build these foundational capabilities at scale.

---

This article is part of our ongoing coverage of Cloud & DevOps. For related reading, see platform engineering and GitOps with Flux and ArgoCD.