Measure Success with DORA Metrics - Part 1- Introduction
In my Team Topologies series, I covered how to organize and structure teams for high performance. But structure alone doesn't tell you whether your teams are actually performing well. How do you know if your organizational decisions are translating into results?
That's where DORA metrics come in. In this series, we'll walk through each stage of the software lifecycle and examine how specific capabilities at each stage drive measurable performance and ultimately business outcomes.
The Software Development Lifecycle
Let’s first define the software life cycle. I like to use the DevOps continuous feedback loop to describe the software life cycle. The entire team is responsible for each stage and has input into how each is executed. The stages I use are:
Plan: This is how the team decides what is worked on next. Infrastructure professionals may advocate for better monitoring and tracing in the application. Developers advocate for a refactoring effort. Project owners will try to push for a new feature customers are asking for. This planning phase is where everything is hashed out.
Build: This is where developers write code and tests builds. Yes, QA is baked into the build process. This process is where non-production environments are leveraged. Infrastructure engineers will build out terraform to support new features or adjust scripts to improve operation tasks.
Deploy: This is the act of moving artifacts into the production environment. It should follow similar processes as production deployment. This is separate from releasing. Just because the artifacts are in the environment, doesn’t mean customers immediately have access to them. That is covered under release. Deploy is a technical decision. Releasing is a business decision. Who gets what may be negotiated in customer contracts or specific features built for a customer may not be available to anyone else.
Release: This is making new value available to customers. It may be business policy that all customers get all features, or the business may be more selective over who gets what. However this is set up, it is a business decision of who gets what when.
Operate: This is the daily running of software. Ensuring infrastructure has the resources to satisfy demand. Scaling up to match spikes and scaling down to save on costs. These operations may be automatic or manual. Here support also answers customer questions and resolves issues. The operate stage is where the team begins to meet customers.
Monitor: This is where feedback is gathered and fed back into the cycle. Monitor doesn’t just mean infrastructure logs, though it does include them. Monitor also means customer questions, issues, and feedback, software performance, infrastructure performance and all other data that is used to influence and help decide priorities on the next thing worked on in the planning stage.
The software development lifecycle doesn’t describe how the lifecycle of the product as a whole. Instead, it describes the lifecycle for individual features. Individual features is where value is derived. Now that we've defined how work flows through the lifecycle, let's talk about how we measure whether it's flowing well.
DORA Metrics
DORA stands for DevOps Research and Assessment. DevOps is a cultural shift that bridges development and operations into a single team. This goes back into Team Topologies we covered earlier. These metrics are backed by over a decade of research and updated every year. The research is based on surveying and interviewing tens of thousands of companies of all sizes and the engineers there. The researchers refine their models, and the results are published every year in DORAs “State of DevOps” reports. These reports form a core model and identifies characteristics in high performing teams. It identifies capabilities that predict performance, which predicts outcomes. The DORA model lets you assess your team’s current performance and identify which capabilities to address to improve outcomes. Let’s dive into the three categories: Outcomes, Performance, and Capabilities.
Outcomes
Outcomes are the things you ultimately care about as a business leader. Profitability. Market share. Customer satisfaction. Operating efficiency. Product quality. These aren't engineering metrics, they're business metrics. But DORA's research has consistently shown that software delivery performance predicts these outcomes.
There are also team-level outcomes that matter: job satisfaction, reduced burnout, and retention. High-performing teams aren't just more productive, they're more stable. You keep your best people longer, and they do better work.
The question is: what drives these outcomes? That's where performance metrics come in.
Performance
We predict our outcomes by measuring our performance. The two disciplines we measure are software delivery and reliability. For software delivery we measure:
Change lead time: how long it takes code to go from written to running in production
Deployment frequency: how often code is deployed to production
Change fail percentage: percentage of deployments that cause failures in production requiring hotfixes or rollbacks
Failed deployment recovery time: how long it takes to recover from a failed deployment
For reliability performance we measure:
Measurement coverage/focus: core reliability measurements (SLIs) in place for critical application components and do they measure customer experience
Target optimization/compliance: reliability targets reflect user sentiment and organizational capability and are these targets met and easily found by team members
These are the metrics we measure. These predict what your business outcomes will be. Now these aren’t the only metrics you should review, but these should all be accounted for. Improving these metrics involves setting policy and culture defined next as capabilities.
Capabilities
The predictor of performance for both software delivery and reliability is drawn from 3 categories, Climate for learning, fast flow, and fast feedback. What policies you set for these capabilities has direct impact on your outcomes. Here is where leaders have control to impact the outcome of the teams.
Climate for learning
Code maintainability: How easily developers can change code they didn't write without breaking things. When code is well-structured and dependencies are managed, teams move faster and onboarding takes days instead of months.
Documentation quality: Critical use cases are documented, ownership is clear, and teams can find what they need without hunting. Documentation isn't busywork, it's how institutional knowledge survives turnover and how new team members become productive.
Empowering teams to choose tools: No one knows what they need better than the team doing the work. When teams can select their own tools, they own the outcomes. When tools are mandated from above, you get compliance without commitment and the performance it’s supposed to bring is lackluster.
Generative culture: This is about trust, information flow, and psychological safety. In generative cultures, failure leads to inquiry, not blame. Ideas flow freely regardless of hierarchy. DORA's research consistently shows this as one of the strongest predictors of performance. We covered this in the Team Topologies series, high trust accelerates flow, low trust kills it.
Fast flow
Continuous delivery: Teams can deploy to production on demand, at any point in the lifecycle. This isn't about deploying constantly, it's about having the capability to deploy whenever the business needs it, without heroics or firefighting.
Database change management: Databases are the hardest part of the stack to change safely. If your application can deploy in minutes but database changes take weeks of coordination, your database is your bottleneck. Change management tooling needs to make database changes as routine as application deployments.
Deployment automation: Manual deployments are slow, error-prone, and don't scale. The more automation in your deployment pipeline, the faster and safer your releases become. Manual intervention should be the exception, not the process.
Flexible infrastructure: Your team should be able to provision what they need, when they need it, without filing tickets or waiting on approvals. This applies whether you're in the cloud or on-prem. Self-service, elastic scaling, and visibility into costs are what matter, not which vendor logo is on the invoice.
Loosely coupled teams: Teams need to test and deploy independently without coordinating across five other teams. This requires both the right architecture and the right team structure. If every release requires a choreographed dance across the organization, you've built in friction that compounds with every new feature.
Streamlined change approval: Heavyweight approval processes, change advisory boards, multi-layer sign-offs, don't reduce risk. They slow releases, which means larger batches, which means more risk. Peer review and automated checks outperform bureaucratic gatekeeping every time.
Version control: Everything that touches production belongs in version control. Application code, database schemas, infrastructure configs, deployment scripts. If it's not versioned, you can't reproduce it, audit it, or roll it back.
Working in small batches: Smaller changes mean faster feedback, easier debugging, and lower risk. When something breaks, you know exactly what caused it. Large releases are a gamble. Small releases are a system.
Fast feedback
Continuous integration: Code is merged frequently and automatically tested on every commit. Problems surface immediately, not three weeks later during a release. CI is the foundation that makes continuous delivery possible.
Monitoring and observability: You need visibility into system health from both technical and user perspectives. Logs, metrics, and traces should tell you what's happening in production before your customers tell you something's wrong. Good observability lets you debug issues interactively, not through guesswork.
Reliability engineering: Failures are inevitable. Reliability engineering is about designing systems that tolerate failures gracefully and recover quickly. This isn't about preventing every outage; it's about minimizing blast radius and reducing recovery time.
Pervasive security: Security isn't a phase you bolt on before release. It's built into the architecture, present in every code review, and part of automated testing. When security is everyone's responsibility from day one, vulnerabilities get caught early instead of discovered in production.
Test automation: Testing happens during development, not after. Automated test suites run on every change, giving developers immediate feedback. Test engineers continuously expand coverage and edge cases. Manual testing doesn't scale; automated testing does.
Test data management: Automated tests are only as good as the data they run against. Stale or unrealistic test data produces meaningless results. Keeping test data current and representative is what makes your test suite trustworthy.
Conclusion
This post establishes the foundation for the series: a software lifecycle that defines how work moves through your organization, and a measurement framework that connects team capabilities to business outcomes.
In the posts that follow, we'll examine each stage of the lifecycle. Plan, Build, Deploy, Release, Operate, and Monitor, mapping the capabilities that matter at each stage. The goal isn't to hit arbitrary metrics. It's to give you visibility into where friction exists and what decisions will move the needle.
Attribution
This article draws on concepts from DORA Research conducted by Google.
Original source materials can be found at the official DORA website: https://dora.dev/research/?view=detail
