DORA metrics measure software delivery throughput and stability through four numbers: deployment frequency, lead time for changes, change failure rate, and time to restore service. SPACE broadens the lens to satisfaction, performance, activity, communication, and efficiency, because velocity numbers alone say nothing about whether developers are burning out to hit them.
| Myth | Reality |
| More commits and pull requests mean higher productivity. | Activity counts are the weakest SPACE signal on their own; they reward busywork as easily as real progress. |
| DORA metrics measure individual developers. | DORA’s four keys measure team and system-level delivery performance, not individual output, and were never designed for performance reviews. |
| Speed and stability are a tradeoff, so fast teams break things more. | DORA research has repeatedly found elite performers ship more often and have lower change failure rates than low performers, not higher. |
| You need a big platform team to start tracking DORA metrics. | The four keys can be approximated from git and CI or CD logs alone before investing in dedicated tooling. |
| Developer experience surveys are just vibes, not data. | Structured, repeated surveys are one of the few ways to capture the Satisfaction and well-being dimension that no system log can measure. |
Why Deployment Counts Alone Do Not Tell the Story
For years, engineering leaders reached for whatever number was easiest to pull from a dashboard: lines of code, commit counts, story points closed per sprint. Google’s DevOps Research and Assessment team, known as DORA, spent close to a decade running large-scale surveys across tens of thousands of practitioners to find out which metrics actually correlated with organizational performance. Their answer was four measures now widely called the four keys, and they hold up because they capture both how fast a team ships and how safely it ships, rather than treating those as opposing forces.
Nicole Forsgren, one of the researchers behind DORA, later co-authored the SPACE framework with Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler, published through ACM Queue and the Communications of the ACM. SPACE exists because DORA’s four keys, useful as they are, only look at the delivery pipeline. They say nothing about whether an engineer is drowning in context switching, whether code review is a bottleneck, or whether the on-call rotation is quietly pushing people out the door. SPACE and DORA are complementary, not competing, and most mature platform teams now track both.
Two Lenses, One Team
A simple two-column visual would show DORA’s four keys on one side, labeled as pipeline and system metrics, and SPACE’s five dimensions on the other, labeled as human and team metrics, with an arrow showing both feeding into a single engineering health dashboard.
The Four DORA Keys, Defined
Deployment Frequency
How often an organization successfully releases to production. Elite performers deploy on demand, often multiple times a day, while low performers may release less than once a month.
Lead Time for Changes
The time from a commit landing in the main branch to that code running in production. Short lead times mean smaller batches, faster feedback, and lower risk per release.
Change Failure Rate
The percentage of deployments that cause a failure in production requiring a fix, rollback, or patch. Contrary to intuition, DORA’s research consistently finds this metric moving together with deployment frequency, not against it.
Time to Restore Service
How long it takes to recover once a failure reaches production. This measures incident response maturity as much as it measures code quality.
| Metric | Elite | High | Medium | Low |
|---|---|---|---|---|
| Deployment frequency | On demand, multiple per day | Between once per week and once per month | Between once per month and once every six months | Fewer than once every six months |
| Lead time for changes | Less than one day | Between one day and one week | Between one month and six months | More than six months |
| Change failure rate | 0 to 15 percent | 0 to 15 percent | 15 to 45 percent | 15 to 45 percent |
| Time to restore service | Less than one hour | Less than one day | Less than one day | One week to one month |
These bands come from Google’s long-running State of DevOps research program and its associated Four Keys project, which teams can use to instrument their own CI or CD systems and see which tier they fall into. The bands shift slightly release to release, but the core pattern, that speed and stability move together rather than trading off, has held across every edition of the report.
The Five SPACE Dimensions, Defined
Satisfaction and Well-Being
How fulfilled developers feel with their tools, team, and work, and whether their job is affecting their health and happiness. Usually measured through structured, recurring surveys rather than system telemetry.
Performance
The outcome and quality of work produced, evaluated by impact rather than volume: did a change move a business or reliability metric, not just how many changes shipped.
Activity
Countable actions like commits, pull requests, code reviews, and documentation edits. SPACE’s authors are explicit that activity is the weakest single-dimension signal and should never be used alone.
Communication and Collaboration
How effectively information, context, and feedback move between people, including discoverability of documentation and quality of code review discussion.
Efficiency and Flow
Whether developers can move through their work with minimal interruption, including the frequency of context switching, wait times for code review, and handoff friction between teams.
Where Teams Actually Struggle
A horizontal bar chart concept would rank the five SPACE dimensions by how frequently teams report them as their weakest area, typically showing Efficiency and flow and Communication and collaboration as the most commonly cited pain points in developer surveys.
Building a Practical Tracking Setup
Start With What Your CI/CD System Already Knows
Deployment frequency and lead time for changes can usually be approximated directly from existing pipeline logs and git history before buying any dedicated tooling. A rough first pass, deployment timestamps joined against commit timestamps, gets a team most of the way to a usable baseline within a day or two of scripting.
Pair Pipeline Data With a Short Recurring Survey
Change failure rate and time to restore service come from incident tooling, but satisfaction and flow have to come from developers directly. A short, consistent quarterly survey, ten to fifteen questions, tends to produce more reliable trend data than a single exhaustive annual survey that people rush through once a year. This kind of lightweight, repeatable instrumentation mirrors the same principle behind well-designed API design practices, where small, consistent contracts outperform one enormous specification nobody maintains.
Report Trends, Not Single Snapshots
A single change failure rate reading means very little. What matters is the trend over several release cycles and whether it moves in the same direction as deployment frequency, confirming the two are reinforcing each other rather than trading off.
Where This Breaks Down in Practice
Common Mistakes
- Turning DORA metrics into an individual scorecard, which research explicitly warns against and which quickly causes gaming of the numbers.
- Tracking activity metrics like commit counts as a proxy for productivity, when SPACE’s own authors call this the weakest dimension in isolation.
- Measuring lead time only from PR open to merge, ignoring the much larger chunk of time code sits waiting for deployment.
- Running an annual, forty-question developer survey instead of a short quarterly one, which produces stale, low-response-rate data.
- Comparing one team’s raw numbers against another team’s without accounting for different deployment models, like mobile app store review cycles versus continuous web deployment.
How Mature Platform Teams Instrument This
A Practical Rollout Pattern
Teams that get durable value from these metrics usually start narrow. They pick two or three DORA measures they can pull from existing systems, publish a simple internal dashboard, and resist the urge to add every SPACE dimension on day one. Only after a few months of stable pipeline data do they layer in a short recurring survey to cover satisfaction and flow. Crucially, they present the numbers as diagnostic tools for the system, not as a ranking of teams or individuals, and they pair any metric that looks worse than expected with a short qualitative conversation before acting on it. This same discipline, instrumenting the system before optimizing it, echoes how teams approach monolith to modular monolith migrations, where measuring coupling and deployment friction comes before any code gets moved.
Where This Fits Into the Rest of the Platform
Developer experience metrics do not live in isolation from the rest of the architecture. Teams migrating toward micro-frontend architectures often see lead time and deployment frequency improve simply because smaller, independently deployable units reduce the blast radius of any single change. Similarly, organizations investing in TypeScript at scale frequently report fewer production incidents tied to type errors, which shows up directly in a falling change failure rate over time. And for teams debating whether a service mesh is worth the operational cost, DORA and SPACE data is often the deciding evidence: if deployment frequency and lead time are already healthy, the case for a mesh usually rests on security and consistency requirements rather than delivery speed.
- DORA metrics
- Four measures of software delivery performance identified by Google’s DevOps Research and Assessment program: deployment frequency, lead time for changes, change failure rate, and time to restore service.
- SPACE framework
- A five-dimensional model of developer productivity covering satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow.
- Lead time for changes
- The elapsed time between a code commit and that code successfully running in production.
- Change failure rate
- The percentage of production deployments that result in a failure requiring remediation, such as a rollback or hotfix.
- Four Keys project
- Google’s open-source reference implementation for instrumenting the four DORA metrics from existing CI or CD and version control data.
- Developer experience (DevEx)
- The overall quality of a developer’s day-to-day working conditions, including tooling, feedback loops, and cognitive load, distinct from raw output volume.
Key Takeaways
- DORA’s four keys measure delivery throughput and stability together: deployment frequency, lead time, change failure rate, and time to restore service.
- Elite performers in DORA research ship more frequently and fail less often, showing speed and stability reinforce rather than trade off.
- SPACE broadens the lens to five dimensions: satisfaction, performance, activity, communication, and efficiency and flow.
- Activity metrics like commit counts are the weakest SPACE signal and should never be used alone to judge productivity.
- Deployment frequency and lead time can usually be approximated from existing git and CI or CD logs before buying dedicated tooling.
- Satisfaction and flow require direct developer input through short, recurring surveys, not just system telemetry.
- Both frameworks are meant to diagnose systems and processes, not to rank individual developers.
FAQs
What are DORA metrics in simple terms?
DORA metrics are four measurements of software delivery performance: how often a team deploys, how long code takes to reach production after being committed, what percentage of deployments cause failures, and how quickly the team recovers from those failures. Together they capture both speed and stability of software delivery.
Who created the DORA metrics?
DORA metrics come from Google’s DevOps Research and Assessment program, which ran multi-year surveys across thousands of engineering organizations through its annual State of DevOps reports. Researcher Nicole Forsgren was a central figure in this work before co-creating the SPACE framework for broader developer productivity measurement.
What is the SPACE framework and how is it different from DORA?
SPACE is a five-dimensional framework covering satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow. Unlike DORA, which focuses specifically on delivery pipeline throughput and stability, SPACE captures the human and team-level factors that influence whether developers can do their best work.
Can DORA metrics be used to evaluate individual developers?
No. DORA metrics were designed to assess team and system-level delivery performance, not individual output, and using them for individual performance reviews tends to encourage gaming the numbers rather than improving delivery. Both DORA and SPACE researchers explicitly caution against this kind of misuse.
What change failure rate should a team aim for?
Based on DORA’s published benchmarks, elite and high-performing teams typically see change failure rates between 0 and 15 percent, while medium and low performers see rates between 15 and 45 percent. The target is not zero failures, since that usually signals overly cautious, infrequent releases rather than genuine reliability.
How do you start measuring DORA metrics without buying new tools?
Deployment frequency and lead time for changes can often be reconstructed from existing CI or CD pipeline logs and git commit history with a modest scripting effort. Change failure rate and time to restore typically require joining that data with an incident tracker, which most teams already run for on-call purposes.
Why does the SPACE framework include activity as a dimension if it is considered weak?
Activity data like commits and pull requests is easy to collect and can reveal useful patterns, such as unusually long gaps in a workflow, when viewed alongside the other four dimensions. The SPACE authors warn against using it in isolation, not against collecting it at all, since context from other dimensions is what makes it meaningful.
How often should developer experience surveys run?
Most engineering organizations get better trend data from a short, ten to fifteen question survey run quarterly than from a long annual survey. Shorter, more frequent surveys tend to have higher response rates and let teams catch satisfaction or flow problems before they show up as attrition or slipping delivery metrics.
- DORA, “State of DevOps Report,” dora.dev
- Google Cloud Blog, “Use Four Keys Metrics to Measure Your DevOps Performance,” cloud.google.com
- Forsgren, Storey, Maddila, Zimmermann, Houck, and Butler, “The SPACE of Developer Productivity,” ACM Queue and Communications of the ACM
- Google, “Four Keys Project,” GitHub (Google open-source Four Keys reference implementation)
