Introduction
Every engineering leader eventually faces the same uncomfortable moment: a quarterly review where someone asks, "How do we know our team is actually getting better?" Velocity charts fluctuate, incident counts bounce around seasonally, and the usual proxy metrics — lines of code, story points, pull request counts — feel simultaneously abundant and meaningless. What we measure shapes what we optimize. And what we optimize determines the culture we build.
Over the past decade, two frameworks have emerged as serious contenders for answering this measurement question. DORA metrics, born from years of large-scale industry surveys by the DevOps Research and Assessment team at Google, give engineering leaders four tightly defined delivery signals. The SPACE framework, introduced in 2021 by researchers at GitHub and the University of Victoria, takes a deliberately broader stance, arguing that developer productivity is inherently multidimensional and resists reduction to any single number. Neither framework is simply "better." But choosing between them — or combining them thoughtfully — requires understanding what each was designed to measure and, equally important, what each was not designed to measure.
This article explores both frameworks in depth, walks through how teams actually implement them, and offers a coaching-oriented perspective on when each framework serves engineers best.
The Problem with Measuring Engineering Work
Software delivery is fundamentally knowledge work, and knowledge work has resisted straightforward measurement for as long as organizations have tried. Frederick Winslow Taylor's industrial efficiency models, applied naively to software, produce perverse incentives. Measure only speed and you get rushed code. Measure only quality and you get over-engineered systems that ship nothing. Measure only test coverage and you get tests that pass but reveal nothing.
The deeper problem is that engineering work is not homogeneous. A senior engineer spending a week on a proof-of-concept architectural spike produces no deployments, closes no tickets, and merges no pull requests — but may unlock months of forward progress. A junior engineer closing fifteen tickets in a sprint may be doing valuable learning work or may be generating technical debt at alarming speed. Any measurement system that fails to account for this variance will, over time, punish exactly the behaviors that compound into excellence.
What makes the DORA and SPACE frameworks interesting is that their authors were aware of this problem from the start. The Accelerate book (Forsgren, Humble, and Kim, 2018), which formalized DORA metrics, was explicit that the metrics were outcomes, not activities — signals of systemic health, not measures of individual effort. The SPACE paper (Forsgren et al., 2021) opened with a direct critique of measuring productivity through output alone. Both frameworks are, at their core, reactions to the inadequacy of the metrics that preceded them.
DORA Metrics: Delivery as the Signal
What DORA Actually Measures
DORA metrics emerged from the State of DevOps survey program, which has collected data from tens of thousands of software professionals since 2014. The four metrics represent the variables most consistently correlated with organizational performance — not just engineering performance, but business outcomes including profitability, market share, and employee satisfaction. This correlation between elite software delivery and business results is DORA's foundational claim, and it has been replicated across multiple years of research.
The four metrics are:
Deployment Frequency measures how often an organization deploys code to production. Elite performers deploy on demand, multiple times per day. Low performers may deploy monthly or less. Frequency serves as a proxy for batch size: teams that deploy rarely tend to accumulate large, risky changes between releases.
Lead Time for Changes measures the time from a code commit to that code running in production. Short lead times indicate that the delivery pipeline is efficient and that feedback loops are tight. A team with a two-week lead time will iterate on customer feedback far more slowly than one with a two-hour lead time, regardless of how clever their engineers are.
Change Failure Rate measures the percentage of deployments that cause a degraded service requiring remediation. This metric keeps Deployment Frequency honest: deploying twenty times a day means nothing if half of those deployments break something. Elite performers maintain a change failure rate below 15%; low performers experience failure rates above 45%.
Time to Restore Service (sometimes called Mean Time to Recovery or MTTR) measures how quickly a team recovers when something does go wrong. Organizations with excellent observability, practiced incident response, and well-understood rollback procedures recover in under an hour. Teams with poor incident culture may take days.
Reading DORA as a System
The power of DORA metrics is not in any single number but in the pattern they reveal together. A team with high deployment frequency and high change failure rate is shipping recklessly. A team with low change failure rate but month-long lead times is over-engineering its quality controls to the point of paralysis. A team with good lead times but poor time to restore is confident until something breaks, at which point it discovers it has no practiced recovery capability.
The research clusters teams into four performance bands — elite, high, medium, and low — defined by thresholds across all four metrics. A team does not reach "elite" by excelling at one metric while neglecting others. This systemic quality is what makes DORA useful as a coaching instrument: it prevents local optimization at the cost of global health.
Implementing DORA in Practice
Measuring DORA metrics requires instrumenting your delivery pipeline. The most natural integration points are your version control system, CI/CD tooling, and incident management platform. Here is a simplified TypeScript example illustrating how you might compute lead time from a pipeline event log stored in a structured format:
interface PipelineEvent {
commitSha: string;
commitTimestamp: Date;
deploymentTimestamp: Date | null;
environment: "staging" | "production";
status: "success" | "failed" | "rolled_back";
}
interface DoraLeadTimeResult {
median: number; // hours
p95: number; // hours
sampleSize: number;
}
function computeLeadTimeForChanges(
events: PipelineEvent[],
windowDays: number = 30
): DoraLeadTimeResult {
const cutoff = new Date();
cutoff.setDate(cutoff.getDate() - windowDays);
const successfulProdDeployments = events.filter(
(e) =>
e.environment === "production" &&
e.status === "success" &&
e.deploymentTimestamp !== null &&
e.deploymentTimestamp >= cutoff
);
const leadTimesHours = successfulProdDeployments.map((e) => {
const diffMs =
e.deploymentTimestamp!.getTime() - e.commitTimestamp.getTime();
return diffMs / (1000 * 60 * 60);
});
if (leadTimesHours.length === 0) {
return { median: 0, p95: 0, sampleSize: 0 };
}
const sorted = [...leadTimesHours].sort((a, b) => a - b);
const median = sorted[Math.floor(sorted.length / 2)];
const p95 = sorted[Math.floor(sorted.length * 0.95)];
return { median, p95, sampleSize: sorted.length };
}
In practice, you would pull this data from your CI/CD provider's API (GitHub Actions, GitLab CI, CircleCI, etc.) rather than a local array. Many observability platforms now offer DORA dashboards out of the box — LinearB, Jellyfish, Faros AI, and DX are among the purpose-built tools in this space, while Datadog and Dynatrace have added DORA tracking to their broader observability suites.
The SPACE Framework: Productivity Beyond Throughput
Why SPACE Was Necessary
The SPACE framework was introduced in a 2021 paper titled "The SPACE of Developer Productivity" by Nicole Forsgren (also a DORA author), Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler. The paper argued that developer productivity had historically been measured too narrowly and that any single-dimensional measurement — including delivery metrics — would produce distorted incentives when used in isolation.
The paper's central claim is that productivity is not a single thing. It emerges from an interaction of five dimensions, each of which can be measured at the level of the individual, the team, or the system. Crucially, SPACE explicitly includes human and qualitative dimensions that DORA does not attempt to capture.
The Five Dimensions Explained
Satisfaction and Well-being addresses whether engineers find their work meaningful, whether they feel they have the tools and support to be effective, and whether their workload is sustainable. This dimension draws on organizational psychology research showing that burnout, disengagement, and attrition are among the most expensive outcomes in engineering organizations. A team shipping fast but burning out will eventually ship nothing at all.
Performance concerns whether the output of engineering work achieves its intended goals. Critically, SPACE defines performance as outcome quality, not output quantity. A feature that ships on time but fails to move a business metric has not "performed" in the SPACE sense, regardless of how many story points it consumed.
Activity covers the quantifiable outputs of engineering work — commits, pull requests, code reviews, documentation contributions, deployments. SPACE does not dismiss these measures; it contextualizes them. Activity data is useful for identifying workflow bottlenecks or understanding how time is distributed across different types of work, but it is not a proxy for productivity on its own.
Collaboration and Communication examines how effectively engineers work together and with adjacent teams. Code review quality, documentation practices, mentorship patterns, on-call burden sharing, and cross-team API design collaboration all fall into this dimension. Research consistently shows that knowledge-sharing and psychological safety are predictors of team-level performance.
Efficiency and Flow measures whether engineers can complete their work with minimal interruptions and friction. Long context-switch times, excessive meeting load, slow build pipelines, and unclear requirements all degrade flow. This dimension has a natural connection to DORA's lead time metric, but extends it into the individual developer's daily experience.
SPACE Is a Framework, Not a Formula
This distinction matters enormously for implementation. DORA gives you four specific metrics with industry-calibrated thresholds. SPACE gives you five dimensions and an argument for why you need to measure across all of them — but it deliberately leaves the choice of specific metrics within each dimension up to the organization. This flexibility is both a strength and a practical challenge.
A team implementing SPACE must answer questions like: How do we measure "satisfaction"? What survey cadence is appropriate? How do we distinguish genuine performance data from activity theater? What does "good collaboration" look like for our context specifically? These questions do not have universal answers, and working through them with a team is itself a valuable coaching exercise.
Comparing the Frameworks: Where They Align and Diverge
What They Share
Both frameworks reject activity as the primary measure of engineering value. Neither framework suggests that pull request count or commit frequency should be used to evaluate individual engineers. Both are grounded in serious empirical research rather than intuition alone. And both treat organizational context as a variable — neither claims that the same thresholds apply equally to a three-person startup and a thousand-person enterprise.
There is also meaningful conceptual overlap between specific DORA metrics and SPACE dimensions. DORA's lead time for changes maps naturally to SPACE's Efficiency and Flow dimension. DORA's change failure rate and time to restore connect to SPACE's Performance dimension. The frameworks are not competitors in the sense of being mutually exclusive — they were designed to answer different questions at different levels of granularity.
Where They Diverge
The most significant divergence is scope. DORA is a measurement framework for software delivery; SPACE is a measurement framework for developer productivity, which is a broader concept. DORA says nothing about whether your engineers feel psychologically safe, whether your on-call rotation is burning people out, or whether your code review culture is producing learning or just gate-keeping. SPACE encompasses all of these — but is correspondingly harder to operationalize with precision.
A second divergence is actionability. DORA metrics are well-defined and increasingly easy to instrument. There is broad industry consensus on what constitutes an "elite" lead time or a "low" change failure rate. SPACE's qualitative dimensions require organizational judgment about what good looks like, and the answers will differ significantly across team contexts, domains, and engineering cultures.
The third divergence is signal stability. DORA metrics are relatively objective and reproducible — given the same pipeline data, two analysts will compute the same lead time. SPACE's Satisfaction and Collaboration dimensions rely heavily on survey data, which is susceptible to response bias, survey fatigue, and semantic drift over time.
Implementation Patterns and Practical Examples
Starting with DORA in a Mid-Sized Engineering Organization
For most teams, DORA is the practical entry point because the data already exists. Your version control history contains commit timestamps. Your deployment logs contain release timestamps. Your incident tracker contains incident open and close times. The initial implementation challenge is stitching these data sources together reliably.
A common first step is creating a deployment event stream. Every time code merges to your main branch and a production deployment succeeds, you emit a structured event with the relevant timestamps. For incident data, you define what "production incident" means in your organization before you start counting — different teams have surprisingly different intuitions about this boundary.
from dataclasses import dataclass
from datetime import datetime
from typing import Optional
import statistics
@dataclass
class DeploymentRecord:
commit_sha: str
commit_at: datetime
deployed_at: datetime
caused_incident: bool
incident_resolved_at: Optional[datetime]
def compute_dora_metrics(records: list[DeploymentRecord]) -> dict:
if not records:
return {}
lead_times_hours = [
(r.deployed_at - r.commit_at).total_seconds() / 3600
for r in records
]
incident_records = [r for r in records if r.caused_incident]
change_failure_rate = len(incident_records) / len(records)
restore_times_hours = [
(r.incident_resolved_at - r.deployed_at).total_seconds() / 3600
for r in incident_records
if r.incident_resolved_at is not None
]
deployment_frequency_per_day = len(records) / 30 # assuming 30-day window
return {
"deployment_frequency_per_day": round(deployment_frequency_per_day, 2),
"lead_time_median_hours": round(statistics.median(lead_times_hours), 1),
"lead_time_p95_hours": round(
sorted(lead_times_hours)[int(len(lead_times_hours) * 0.95)], 1
),
"change_failure_rate_pct": round(change_failure_rate * 100, 1),
"mean_time_to_restore_hours": (
round(statistics.mean(restore_times_hours), 1)
if restore_times_hours
else None
),
}
Once you have a working pipeline, the coaching conversation shifts from "how do we get data?" to "what does this data tell us?" A team discovering that its lead time is twelve days will typically find the explanation distributed across a few persistent bottlenecks: a slow test suite, a manual QA sign-off step, an infrequent deployment window, or a culture of holding PRs open for days awaiting review. DORA makes the problem visible; the team's knowledge makes it actionable.
Layering in SPACE for Coaching Depth
DORA tells you that your change failure rate is 40% and your lead time is eight days. It does not tell you whether your engineers are exhausted, whether your code review culture is creating knowledge silos, or whether the team's flow is constantly fractured by cross-functional Slack requests. To understand these dynamics, you need SPACE's qualitative dimensions.
A practical implementation of SPACE typically begins with a lightweight developer experience survey deployed on a regular cadence — biweekly or monthly. The survey asks targeted questions across each dimension, keeping it short enough that engineers actually complete it. Tools like DX, Pluralsight Flow, and GetDX have built survey instruments specifically designed around SPACE's taxonomy, though many teams build their own with Typeform or internal tooling.
The key insight for coaching is triangulation. When DORA shows degrading lead time and the SPACE Efficiency dimension survey shows that engineers report high interruption frequency and unclear requirements, you have converging evidence pointing at a specific intervention: protect engineering focus time and improve upstream clarification of work. Either signal alone is easier to dismiss; together, they are hard to argue with.
Trade-offs and Pitfalls
Goodhart's Law Is Watching
The most dangerous failure mode for any measurement framework in engineering is Goodhart's Law: when a measure becomes a target, it ceases to be a good measure. This dynamic is not hypothetical — it has been observed repeatedly in engineering organizations that tied DORA metrics to performance reviews or team bonus structures.
Deployment frequency is particularly susceptible. A team incentivized to maximize deployment frequency will decompose work into tiny, barely meaningful deployments. Lead time can be artificially shortened by removing useful quality steps from the pipeline rather than genuinely improving throughput. Change failure rate can be understated by redefining what constitutes a "failure." Every DORA metric has a corresponding gaming strategy, and any organization that creates strong incentives around these numbers will eventually discover at least one of them.
The antidote is to treat DORA metrics as diagnostic instruments, not performance scorecards. A thermometer is useful for understanding a patient's condition; it is useless for evaluating a nurse. The same metric used in two different contexts carries entirely different implications for how people will relate to it.
Survey Fatigue and SPACE Validity
SPACE's qualitative dimensions depend heavily on survey data remaining trustworthy over time. This trust erodes predictably under a few conditions. If engineers perceive that survey responses are connected to performance evaluations, they will optimize their responses rather than answer honestly. If surveys are too long or too frequent, response rates drop and selection bias corrupts the signal. If leadership is seen as ignoring survey results, engineers will stop completing them.
Maintaining survey validity requires an explicit social contract: the data is used to improve the system, not to evaluate individuals; responses are aggregated and anonymized before leadership sees them; and the team sees evidence that survey feedback produces concrete changes. Without these structural guarantees, SPACE's most valuable dimension — satisfaction and well-being — becomes a measurement of psychological safety about the survey itself, not about work.
The Vanity Metrics Problem for Individuals
Both frameworks are explicitly designed for team and organizational analysis, not individual assessment. This is not an accident — applying outcome-level metrics to individual engineers produces both statistically unreliable results (sample sizes are too small) and profound fairness problems (a senior engineer focused on technical debt reduction will score poorly on activity metrics compared to a junior engineer closing straightforward tickets).
This boundary must be made explicit and defended consistently by engineering leaders. In organizations where the measurement culture is anxious or punitive, frameworks that were designed as team health instruments will inevitably be misappropriated as individual performance tools. Resisting this misappropriation is as important as getting the instrumentation right.
Best Practices for Implementation
Start with a Diagnosis, Not a Benchmark
Before asking "how do we score on DORA?" ask "what are we trying to understand?" Different engineering challenges call for different diagnostic emphasis. A team struggling with production reliability benefits most from a focused look at change failure rate and time to restore. A team that ships slowly despite high individual talent benefits most from lead time decomposition. A team experiencing attrition needs SPACE's satisfaction and well-being dimension before it needs deployment frequency data.
The frameworks are tools. Picking up a tool before diagnosing the problem is a reliable path to wasted effort and demoralized engineers who feel surveyed without being heard. A good coaching engagement begins with qualitative conversations — retrospectives, one-on-ones, team health checks — that reveal which questions the measurement framework should answer.
Establish Baselines Before Setting Targets
One of the most common implementation mistakes is setting DORA targets before understanding where a team currently sits. An organization that is deploying monthly and sets a one-week lead time target is likely to generate anxiety rather than progress. The research suggests that performance bands should be treated as directional orientation, not immediate benchmarks: the goal is to understand which band you're in and to identify the highest-leverage constraints preventing movement to the next band.
Baselines should be computed over at least ninety days of data to smooth out seasonal variation, major incidents, and natural deployment cycle fluctuations. They should be reviewed in team retrospectives rather than delivered as reports from leadership, because the team closest to the work will often immediately recognize patterns that are invisible to external observers.
Make the Measurement Visible and Shared
Metrics that live in leadership dashboards but never appear in team rituals have limited coaching impact. The most effective implementations of both frameworks make the data visible at the team level — in sprint reviews, in team wikis, in lightweight dashboard screens accessible to everyone. When engineers can see their own DORA trends over time, they develop an intuition for what the numbers mean in practice and become more effective at connecting daily decisions to systemic outcomes.
SPACE survey results should be shared at the team aggregate level as soon as they are collected, with a dedicated team session for discussing what the results reveal and what experiments the team wants to run in response. This rhythm — survey, review, experiment, resurvey — is what makes SPACE's qualitative dimensions practically actionable rather than academically interesting.
Invest in Psychological Safety First
Neither framework works without psychological safety. DORA metrics will be gamed if engineers fear that high change failure rates will result in blame. SPACE surveys will produce meaningless data if engineers do not trust that honest responses are safe. This is not a measurement problem — it is a leadership culture problem, and it cannot be solved by choosing a better framework.
Engineering leaders implementing either framework should be explicit about the purpose: these measurements exist to understand system behavior and to remove obstacles for the team, not to identify underperformers. This framing should be reinforced consistently and demonstrated behaviorally. When a DORA metric worsens, the first question should be "what changed in the system?" not "who is responsible?"
An 80/20 Perspective: The Concepts That Drive Most of the Value
Across both frameworks, a small number of concepts generate most of the practical insight:
Batch size is arguably the most powerful lever in software delivery. Small, frequent changes reduce risk, accelerate feedback, and compress lead time. High deployment frequency is a downstream consequence of teams that have learned to decompose work into small, independently deliverable increments. Almost every DORA metric improves when batch size decreases.
Flow efficiency — the ratio of active work time to total elapsed time — explains most lead time variation that is not caused by batch size. A task that requires four hours of actual work but takes eight days to travel through review, staging, and deployment approval is not a development problem; it is a pipeline friction problem. Identifying and eliminating these wait states has outsized leverage on lead time.
Incident learning culture determines whether your time-to-restore metric improves over time. Organizations that run blameless postmortems, share incident learnings broadly, and track follow-up work actually see their MTTR trend downward. Organizations that treat incidents as embarrassments to be minimized see MTTR stay flat or worsen.
Developer experience investment is the strongest predictor of SPACE's Efficiency and Flow metrics. Teams that have fast local development environments, reliable CI/CD pipelines, and low-friction tooling report substantially higher flow scores than teams fighting their tools. This investment is often deprioritized because its ROI is diffuse — every engineer benefits a little every day — but it compounds dramatically over time.
Key Takeaways
For engineering leaders and coaches looking for immediate next steps:
-
Instrument your delivery pipeline first. You cannot improve DORA metrics you are not measuring. Spend a sprint creating reliable deployment event tracking and connecting it to your incident management data. This foundational data collection will generate insights before you have even started formal analysis.
-
Conduct a SPACE dimension audit before your first survey. Walk through each SPACE dimension with your team leads and identify which dimensions you already have data for (activity, efficiency proxy through build times), which you have no data for (satisfaction, collaboration quality), and which dimensions feel most pressing given your current team health signals.
-
Adopt a "systems, not individuals" framing publicly and persistently. Every time a metric comes up in a team conversation, model the habit of asking "what does this tell us about our system?" rather than "who is responsible for this?" This reframing has to come from leaders and has to be consistent to change the team's relationship to measurement.
-
Run DORA and SPACE retrospectives on different cadences. DORA metrics benefit from monthly trend reviews because they need enough data to be statistically meaningful. SPACE surveys benefit from higher frequency — biweekly or monthly — because their value is in detecting rapid shifts in team sentiment or collaboration patterns.
-
Start with two or three metrics from each framework, not the full complement. Measurement systems that are too comprehensive create analysis paralysis and survey fatigue before they generate actionable insights. Pick the metrics most relevant to your current coaching goals, stabilize your collection and review process around them, and expand incrementally as the team develops data literacy.
Analogy: DORA and SPACE as Different Medical Diagnostics
Think of a hospital's approach to patient health. A pulse oximeter gives you one clean, reliable number: blood oxygen saturation. If it reads 94%, you act. If it reads 99%, you are reassured. DORA metrics are the pulse oximeter of software delivery: precise, actionable, and excellent at flagging that something is wrong, even when the specific diagnosis requires further investigation.
A full metabolic panel, by contrast, measures dozens of variables across multiple biological systems. It takes longer to run, requires expert interpretation, and produces findings that cannot easily be reduced to a single number. The SPACE framework is the metabolic panel: it captures a richer picture of organizational health, but translating that picture into action requires judgment and context that no framework can substitute for.
Neither instrument replaces the other. The oximeter is not primitive because it only measures one thing; the metabolic panel is not bloated because it measures many. An experienced clinician knows when to reach for each one, and knows that the most important diagnostic tool is still the conversation with the patient. For engineering coaches, the frameworks are instruments. The team conversations are the clinical judgment.
Conclusion
DORA metrics and the SPACE framework are complementary answers to the same underlying question: how do we understand the health and performance of engineering work well enough to improve it systematically? DORA provides a rigorous, well-calibrated signal for delivery throughput and stability — the "can we ship?" question. SPACE provides a richer but harder-to-operationalize lens for the full human experience of engineering — the "can we sustain?" question.
For most engineering leaders, the practical path forward is to start with DORA as the measurement foundation, invest in the pipeline instrumentation required to compute it reliably, and use the resulting retrospective conversations to identify which SPACE dimensions most need attention given the team's current situation. As measurement maturity grows, the SPACE dimensions provide depth that pure delivery metrics cannot supply — particularly the satisfaction, well-being, and collaboration signals that predict team stability and retention over longer time horizons.
The choice of metrics is ultimately a choice about what kind of conversations you want to have with your team. Metrics that measure only throughput will produce conversations about speed. Metrics that also measure human experience will produce conversations about sustainability, growth, and the conditions under which people do their best technical work. The latter conversations are harder, slower, and more ambiguous. They are also the ones that actually build the teams that build great software.
References
- Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. IT Revolution Press.
- Forsgren, N., Storey, M.-A., Maddila, C., Zimmermann, T., Houck, B., & Butler, J. (2021). "The SPACE of Developer Productivity." ACM Queue, 19(1). https://queue.acm.org/detail.cfm?id=3454124
- DORA Research Program. State of DevOps Report (annual). Google Cloud. https://dora.dev
- Forsgren, N., Smith, D., Humble, J., & Frandson, J. (2019). DORA State of DevOps 2019. DORA / Google Cloud.
- DeMarco, T., & Lister, T. (1987). Peopleware: Productive Projects and Teams. Dorset House Publishing. (Foundational work on flow, productivity, and knowledge work environments.)
- Humble, J., & Farley, D. (2010). Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley. (Provides the technical foundations underlying DORA's lead time and deployment frequency concepts.)
- Skelton, M., & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press. (Complements both frameworks with organizational design thinking around cognitive load and team interaction modes.)
- Goodhart, C. A. E. (1984). "Monetary Theory and Practice." In Problems of Monetary Management: The U.K. Experience. Macmillan. (Original formulation of Goodhart's Law, essential context for understanding measurement risk.)