Every engineering leader eventually hears the same questions from the business. Are we delivering fast enough? Is quality improving? Is the investment in tooling and platform paying off? Answering with anecdotes is unsatisfying, and answering with the wrong numbers is dangerous. Lines of code, number of commits, story points completed, and hours logged are easy to collect, but they measure activity rather than outcomes, and they can be gamed in ways that make software worse.

Over the past decade, research has given the industry better answers. The DevOps Research and Assessment program, known as DORA, identified a small set of metrics that predict both software delivery performance and organizational outcomes. The SPACE framework, published in 2021 by researchers from Microsoft, GitHub, and the University of Victoria, argued that productivity is multidimensional and cannot be captured by any single number. More recently, attention has turned to developer experience as a leading indicator of both speed and quality.

This article explains these ideas, shows how to collect and interpret the metrics, describes the pitfalls that turn measurement into harm, and walks through a worked example of a team using metrics to find and remove a bottleneck.

Why Measuring Software Delivery Is Hard

Software development is knowledge work. Its outputs are intangible, its effort is hard to compare across tasks, and its value depends on whether the right things were built, not merely on how much was built. A developer who deletes a thousand lines of obsolete code may contribute more than one who adds a thousand.

Goodhart's law captures the central danger: when a measure becomes a target, it ceases to be a good measure. If teams are rewarded for closing tickets, they split tickets into tiny pieces. If they are judged on test coverage percentages, they write tests that execute code without asserting anything. If individuals are ranked by commit counts, they commit more often and collaborate less. Poorly chosen metrics do not merely fail to help, they actively redirect effort toward the metric and away from the goal.

The solution is neither to avoid measurement nor to find a perfect metric. It is to choose measures that reflect outcomes, use them at the right level, combine several that balance each other, and apply them to learn rather than to punish.

The Four Key DORA Metrics

Starting in 2014, the DORA team surveyed tens of thousands of professionals, and analyzed the results statistically in the annual State of DevOps reports and in the book Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim. They found four measures that together distinguish high-performing organizations. Two capture throughput and two capture stability.

Deployment frequency measures how often an organization successfully releases to production. Elite performers deploy on demand, multiple times per day, while low performers deploy monthly or less. Frequent deployment implies small batch sizes, automation, and confidence.

Lead time for changes measures the time from a code commit to that code running in production. Short lead times mean fast feedback, quick delivery of value, and the ability to respond to problems rapidly. Elite teams measure this in hours or less; low performers measure it in months.

Change failure rate measures the percentage of deployments that cause a failure in production requiring remediation, such as a rollback, hotfix, or patch. It captures the quality of what is being released.

Time to restore service, sometimes called mean time to recovery, measures how long it takes to recover from a failure in production. Since failures are inevitable, the ability to detect and fix them quickly matters as much as preventing them. More recent DORA research refined this to failed deployment recovery time, focusing on failures caused by changes.

The most important finding was that speed and stability are not trade-offs. High performers do well on all four at once, because the practices that enable fast delivery, such as small changes, automated testing, and trunk-based development, also improve quality. This overturned the common belief that going faster means breaking more.

In recent years DORA has also emphasized reliability as a fifth dimension, and has used cluster analysis rather than fixed thresholds to describe performance levels, so teams should treat published benchmarks as rough context, not as rigid targets.

What Drives the Metrics: Capabilities

DORA's greatest value lies not in the four metrics but in the list of capabilities that predict them. These include continuous integration, trunk-based development, test automation, deployment automation, loosely coupled architecture, monitoring and observability, version control for everything, working in small batches, and a generative organizational culture based on trust and information flow. Teams that want to improve the metrics should invest in these capabilities rather than manipulating the numbers directly.

This is why the metrics are best understood as diagnostic indicators. They tell you where to look, and the capabilities tell you what to change.

The SPACE Framework

While DORA concentrates on delivery performance, the SPACE framework addresses the broader question of developer productivity. Its authors, Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler, proposed five dimensions, whose initials give the framework its name.

Satisfaction and well-being captures how fulfilled developers are with their work, team, tools, and culture, and whether they are at risk of burnout. Performance captures outcomes of the system or process, such as quality, reliability, and customer impact, instead of output volume. Activity counts the quantity of actions or outputs, such as commits, pull requests, or incidents handled; it is useful context but dangerous alone. Communication and collaboration looks at how people and teams work together, including the quality of code review, onboarding speed, and the discoverability of documentation. Efficiency and flow measures the ability to complete work with minimal delays and interruptions, including handoffs, wait times, and the amount of uninterrupted focus time.

The framework offers several practical rules. Capture metrics across at least three dimensions at once, so that gains in one area cannot hide losses in another. Include perceptual measures from surveys alongside system data, since developers' own experience reveals problems that telemetry cannot. And remember that individual-level metrics are often misleading, because productivity depends heavily on the team and the system. SPACE does not prescribe specific metrics. It is a lens for designing a measurement set suited to a given context.

Developer Experience as a Leading Indicator

A natural extension is the idea of developer experience, often shortened to DevEx. It focuses on how developers feel about and interact with their working environment, and it is supported by research from Abi Noda, Margaret-Anne Storey, Nicole Forsgren, and Michaela Greiler, who proposed three core dimensions: feedback loops, cognitive load, and flow state.

Feedback loops are the speed and quality of responses developers get from tools and people: how long builds, tests, and code reviews take, and how quickly questions are answered. Cognitive load is the mental effort needed to complete a task, driven by complex codebases, unclear documentation, and too many tools. Flow state is the ability to focus and make progress with minimal interruption, shaped by meeting load, on-call burden, and the clarity of goals.

Developer experience matters because it leads outcomes rather than lagging them. Slow builds and unclear processes drain time and morale before they ever show up in lead time or attrition statistics. Measuring it typically involves short, regular surveys asking developers to rate aspects such as ease of releasing, code review turnaround, confidence in tests, and time lost to tooling, combined with system data such as CI duration and queue time. Platform engineering teams increasingly use these measures to prioritize investments in internal developer platforms.

Collecting the Data

Most DORA data can be gathered from systems the team already uses. Deployment frequency comes from the deployment pipeline or release tool. Lead time can be computed by linking commits in version control to deployment events. Change failure rate requires a consistent definition of failure, usually derived from incident records, rollbacks, or hotfix deployments linked to the originating change. Time to restore comes from the incident management system, measured from detection to resolution.

Open-source and commercial tools make this easier. Four Keys, an open-source project from Google, builds a dashboard from GitHub or GitLab and incident data. Commercial platforms such as LinearB, Jellyfish, Swarmia, Sleuth, and DX provide similar and broader insights, and observability vendors increasingly include delivery metrics. Whatever the tool, the most important task is to agree on definitions. What counts as a deployment? When does lead time start? What qualifies as a failure? Without clear, shared definitions, numbers will vary between teams and be impossible to compare.

Data quality deserves attention. Incident tickets that are created late or closed carelessly distort recovery time. Squashed commits and long-lived branches obscure lead time. Teams should treat the pipeline of measurement itself as something to be reviewed and improved.

How to Use Metrics Wisely

Several principles separate productive use from harmful use.

Measure at the team or system level, not the individual level. Delivery is a collective achievement, and ranking individuals by metrics destroys collaboration and encourages gaming. Use metrics to ask what is slowing the team, not who is slow.

Focus on trends, not absolutes. Comparing one team to another is misleading because contexts differ: a team maintaining a regulated medical device operates under different constraints than one running a consumer website. Compare a team to its own past, and look for direction and variance.

Pair metrics so they balance each other. Increasing deployment frequency while watching change failure rate prevents recklessness. Reducing lead time while watching developer satisfaction prevents burnout.

Use metrics to start conversations. A number is a prompt for investigation, not a verdict. When lead time rises, the retrospective should ask why, and the answer will usually be found by talking to the people involved.

Never tie metrics directly to individual performance reviews or compensation. The moment they are used as targets, they will be gamed, and trust in the data will collapse. Leadership should be explicit about this commitment.

Combine quantitative and qualitative evidence. Surveys, interviews, and observation reveal why the numbers look the way they do.

Common Anti-Patterns

Several well-known mistakes recur. Treating output metrics such as velocity as productivity targets leads to inflated estimates. Using story points to compare teams is meaningless because points are relative to each team. Counting lines of code rewards verbosity. Measuring utilization or hours worked rewards presence rather than progress and leaves no slack for improvement or innovation. Publishing leaderboards of developers breeds resentment. Adopting a tool and dashboard without deciding what decisions they will inform results in charts nobody uses. And optimizing a single metric in isolation, such as pushing deployment frequency by deploying empty or trivial changes, produces numbers that look good while delivering nothing.

A Worked Example: Finding the Bottleneck

Consider a product team of eight engineers in a mid-sized company. Leadership wants to know whether the team is delivering well, and the team lead decides to establish a baseline using DORA metrics and a short developer survey.

The team first agrees on definitions. A deployment is a release of the main service to production. Lead time runs from the first commit in a pull request to successful deployment. A failure is any deployment followed by a rollback, hotfix, or incident within 24 hours. They pull data from their repository, pipeline, and incident tracker for the past quarter.

The results are as follows. Deployment frequency is about once every nine days. Median lead time for changes is eleven days. Change failure rate is 8 percent. Median time to restore is 50 minutes. The failure rate and recovery time are respectable, but the delivery speed is slow. The survey, taken by all eight engineers, adds context: they rate confidence in tests as high, but they rate release process as poor, and the free-text comments mention waiting for approvals and a manual regression stage.

To find the cause, the team breaks lead time into stages. Coding time, from first commit to pull request, takes about one day. Review time, from pull request open to approval, takes two days. The time from merge to deployment takes eight days, because releases are batched into a bi-weekly release train that requires a manual sign-off by a separate quality group and a four-hour manual regression test. The bottleneck is not development or review; it is the release process.

The team forms a hypothesis: automating the regression checks and moving to deployment on merge, protected by feature flags and automated canary analysis, will cut lead time without raising the failure rate. They convert the most valuable manual checks into automated end-to-end tests over two sprints, add a progressive rollout with automatic rollback on error-rate increase, and replace the manual sign-off with automated policy checks and a review of high-risk changes only.

Three months later, they re-measure. Deployment frequency rises to roughly daily. Median lead time falls to two days. Change failure rate is 6 percent, slightly better, because changes are smaller. Time to restore improves to 20 minutes thanks to automatic rollback. In the follow-up survey, satisfaction with the release process rises from poor to good, and engineers report fewer interruptions. The team also watches for unwanted effects: review time has crept up slightly because pull requests arrive more often, so they agree on a norm of reviewing within four working hours.

The important lessons are visible. The metrics identified where to look. The stage breakdown located the bottleneck. The survey confirmed the human impact. The improvement came from capabilities, not from pressure to hit a number. And the team presented its results to leadership as a story about removing friction, not as a score.

Getting Started

An organization can begin modestly. Choose one or two pilot teams. Agree on the four DORA definitions and instrument them from existing systems. Run a short quarterly survey on developer experience with five to ten questions. Review the results together in retrospectives, pick one improvement, and measure again. Share findings openly, including setbacks, and resist the temptation to roll out company-wide scoreboards. As trust grows, extend the practice, add dimensions from SPACE such as collaboration and well-being, and connect the data to investment decisions such as platform priorities and tooling budgets.

Conclusion

Good measurement helps engineering organizations see themselves clearly. The DORA metrics offer a small, validated set of indicators for delivery speed and stability. The SPACE framework reminds us that productivity has many dimensions and that people's experience matters as much as system data. Developer experience provides early warning of friction before it becomes an outcome.

Used with care, these tools support honest conversations, targeted investment, and continuous improvement. Used carelessly, they become instruments of surveillance and gaming. The difference lies in intent: measure systems, not individuals; watch trends, not rankings; balance speed with stability and well-being; and always follow the numbers back to the people and practices that produce them.