DORA Metrics: Drive Kickass Engineering Performance

7 min readNov 24, 2024

Introduction: Why DORA Metrics Matter

As an engineering leader, you’ve probably heard about DORA metrics and might wonder: Are they just another management buzzword or a real tool for improvement? Spoiler alert: They’re the latter.

The DORA (DevOps Research and Assessment) metrics, developed by Google’s DevOps Research Team, are four key indicators that separate high-performing engineering teams from the rest. Even though they don’t provide the full picture, they tell a lot about your engineering organization, mainly about delivery bottlenecks.

The Four DORA Metrics Explained

The DORA metrics tell us about speed and quality. The research classified teams into performance buckets:

The metrics are per team because this is the unit of execution.
Not individuals, no averages between teams and no accumulation. It’s unhelpful to know that the organization is “ok on average”. The idea is to find opportunities to improve within the context of each team.

This performance classification is general to the industry and teams can be very different from each other in context, speed and process. For example, a firmware, mobile or web SaaS, and comparing them doesn’t make a lot of sense. The idea is for each team to improve itself and compare with its past self.

Let’s explore each metric:

1. Deployment Frequency 🚃

What It Means: Speed — how often does your team release to production?
Elite Performers: Deploy multiple times per day (whether monolith or microservices)
How to Measure: Count all deployments to production
Why:

Short feedback loop from the customers
Encourage frequent integration
Lower risk when changes are smaller
Easier to identify root cause of failures
Higher frequency means we’re confident; not afraid to deploy

2. Lead Time for Changes ⏳

What It Means: Speed — how long does it take to go from first code commit to production?Elite Performers: Less than one hour
How to Measure: Calculate time between first commit and production deployment
Why:

Small changes are reviewed more quickly and get to production fast
Bring value incrementally to customers, short feedback loop
Less chance of a “big bang release” — a big and risky change

3. Mean Time to Recovery (MTTR) 💥

What It Means: Quality — how quickly can you restore functionality after an incident?
Elite Performers: Less than one hour
How to Measure: Calculate time between incident detection and system restoration
Why:

Failures are inevitable, so we’d better recover fast
Simpler, smaller changes contribute to faster root cause analysis and faster recovery
Requires adequate tooling, robust infrastructure and process, battle-tested restoring

4. Change Failure Rate 🚑

What It Means: Quality — what percentage of deployments cause failures in production?
Elite Performers: 0–15% failure rate
How to Measure: Count deployments that result in incidents, broken system tests, rollbacks, or service disruptions
Why:

Measures how often things really break
Encourages preparation in the form of testing and runbooks
Smaller, lower risk changes increase confidence and result in fewer failures

Tools for Measuring DORA

It’s possible to write your own tool to extract all DORa metrics, but it’s a bit like writing your own email server when you’re not in the email business. There are affordable and tested tools that do just that without spending engineering time on it. Most connect very easily to git, Github and Jira (or whatever you’re using) and provide dashboards.

The one I worked the most with is Sleuth [I am a mere user, not a partner or an affiliate].
Some additional information such tools can provide:

Flagging “items at risk” — too few tests, high percentage of rework, longer than expected development time
Batch size distribution — shows how many of the pull requests were large, medium and small (we prefer small ones)
Development time breakdown — waiting for code review, review time, etc.

You can already see that such data points surface opportunities for improvements.

Practical Steps to Improve DORA Metrics

So, we have accurate data and nice dashboards. What do we do with them?
How to interpret values and trends?

When I just started looking at the dashboards a few years back, I didn’t know how to interpret them. The data was reliably there, but I wasn’t sure what actions to take. It was evident that changes in circumstances or deliberate modifications of the ways of working were making an impact. For example, when half the team was on security training, the number of deployments dropped. When we fixed flaky tests, the failure rate dropped. When we eliminated manual testing efforts, the lead time dropped.

As mentioned above, DORA published industry benchmarks to compare to, e.g. “elite team”, but setting a DORA goal, such as “Make sure your team reaches 2 deploys per day” might fail the learning process, cause gamification and reduce trust.

A better option is for the team to look weekly at their metrics for the past week or two, e.g. in standup or during retro, and find opportunities for improvements within their context. They can also spot positive and negative trends and make decisions as a result.

As an engineering leader responsible for these teams, you’d better keep your finger on the pulse and review the metrics weekly, perhaps with the engineering manager. This is useful because it signals that it’s important, it helps the managers remain accountable and explain any anomalies and prevent teams from overlooking them when they are so focused on tactics and implementation.

When interpreting the data from the metrics is still unclear you can reach out to experienced colleagues, online articles or consultants like myself.

Here are a few examples. As you go over them, think for yourself which metrics they can improve and how:

1. Continuous Integration and Deployment

Implement automated robust CI/CD pipelines
Automate testing instead of manual effort
Use feature flags to release frequently
Practice trunk-based development — usually a dramatic improvement in metrics is evident when switching from the pull request model to pairing with trunk-based development

2. Reduce Complexity

No “handover” steps or separate roles for discovery, development, testing, deployment
Small user stories, quick iterations
Small batches (commits, pull requests)
Low WIP limit (limit the number of tickets the team can simultaneously work on)
Separate changes of tech debt from user stories (make the change easy, then make the easy change)
Trade-off breaking a monolith into (micro)services
Domain ownership per team (few dependencies, end-to-end responsibility)
Use infrastructure as code
Standardize development practices

3. Improve Observability

Collect metrics about usage of business cases, endpoints latency, errors, traffic size, cache effectiveness, queue size, etc. (not only CPU and memory)
Invest in monitoring and alerting based on these metrics
Create clear incident response protocols (runbooks) with disaster recovery exercises
Implement comprehensive logging and error tracking

4. Foster a Learning Culture

Allow long focus time for members
Maintain internal documentation
Conduct blameless postmortems
Encourage knowledge sharing
Invest in continuous learning
Create psychological safety
Fix root issues of support cases

Rollout

When introducing DORA for the first time, members might be suspicious about why all of a sudden there are additional measurements. If there is no good communication, they’d assume it’s for spying on them and it will have an impact on their individual performance review.

The introduction of DORA metrics to an organization requires good and transparent communication about the “why” and how the metrics would serve the teams, and will not incur punishments or comparison between teams. Educating is crucial: repetition about the goals, publishing internal FAQs, explanation about the specific tool you’ve chosen and how to use the data. Moreover, being with the teams in the beginning can help remove the confusion and uncertainty.

Many organizations start with a single team that serves as a pilot and for gathering learnings, then expand to additional teams. And as with everything new, it may take some time until it’s clear and useful.

Common Pitfalls to Avoid

Don’t chase metrics blindly

Metrics are guides, not goals
Context always matters
Balance speed with quality; improving one at the expense of the other will backfire
Team defaulting to busywork, sacrificing business value to pursue DORA metrics

Avoid comparing across teams

Different products have different challenges. E.g. a mobile app might take a whole week for approval (you can consider it a successful deployment)
Even teams with similar architectures and domains might have varying size and maturity levels and customer types

Don’t neglect human factors

Metrics don’t tell the whole story, the team is not a dashboard
Combine quantitative data with qualitative insights — team members often know the problems and challenges. The metrics help remove the subjectivity

Realistic Expectations

Improving DORA metrics is a journey, not a destination. High-performing teams didn’t become great overnight. Expect:

Initial dip in productivity during transformation
Resistance to change
Need for continuous learning, support and adaptation
Fear that it will impact their performance review and metrics will be collected per individual — explain and repeat that it’s for teams to improve

What DORA Doesn’t Tell Us

if we’re building the right thing
about PMF (product-market fit) or sales issues
how sustainable we are
about staff retention
if we’re aligned with the company values
average of all teams is meaningless

For this additional data, we can measure things like OKRs progress, talk to members in 1:1s, quick iterations with customers to validate experiments, alerts after working hours, time breakdown (user stories, bugs, support work, “technical work”), costs, and the more extensive SPACE and DevEx frameworks.

Final Thoughts

DORA metrics are about creating a culture of continuous improvement, learning and excellence.

Your goal isn’t to have perfect metrics. Your goal is to create an environment where your engineers can do their best work with minimal friction.

Pro Tip: Start small. Pick one metric, make incremental improvements and celebrate progress.