Beyond the Four DORA Metrics: SPACE, DevEx & DX Core 4

The Gap in the Four Metrics

The DORA metrics guide on this blog describes four indicators that have become the gold standard for software delivery performance: Deployment Frequency, Lead Time for Changes, Mean Time to Restore, and Change Failure Rate. These metrics are robust, empirically validated, and an excellent starting point. But they have a systematic blind spot that becomes increasingly painful as an organization matures: they measure the output of the delivery system, not the experience of the people who operate it.

A team can deploy multiple times per day, hold a lead time under one hour, and still be burned out. An organization can reach elite values across all four DORA dimensions while simultaneously running an attrition rate that erodes every quarterly result. The DORA metrics do not see this. They see the throughput and stability of the pipeline — not the friction a developer experiences before code is even committed, and not the cognitive load that every change incurs in a poorly understood system.

In 2026, this gap is no longer an academic detail. With the widespread adoption of AI coding assistants, the bottleneck shifts away from the pure act of writing code toward understanding, reviewing, and integrating it. Throughput rises — but stability and comprehension come under pressure when the supporting practices fail to scale with it. This is exactly where the complementary frameworks come in: SPACE and DX Core 4 measure what DORA structurally cannot see.

This article does not replace DORA — it expands it into a complete measurement system. The thesis: top-quartile teams do not emerge from a single metric but from the deliberate combination of DORA, SPACE, and DX Core 4. Teams that read all three layers together identify bottlenecks four to five times earlier than teams that only watch pipeline throughput.

What the SPACE Framework Measures

SPACE was introduced in 2021 by a group of researchers including Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler. It is not a competing model to DORA but a framework that deliberately makes one point clear: developer productivity is multidimensional and cannot be reduced to a single number. SPACE is an acronym for five dimensions that together paint a far more complete picture than throughput metrics alone.

Satisfaction and Well-being captures how content and healthy a team is — burnout signals, intent to leave, the sense of working with the right tools. This dimension is so central because dissatisfied teams often hold their DORA values for a while before they collapse. Satisfaction is a leading indicator where DORA is a lagging one.

Performance measures the outcome of a system or process — deliberately not the activity of an individual. This is where the DORA stability metrics attach. Activity captures the count of actions or outputs — commits, pull requests, reviews. The explicit warning of the SPACE model: activity alone is never a productivity measure, only a contextual signal.

Communication and Collaboration surfaces how information flows through the team — how quickly a pull request finds a reviewer, how discoverable documentation is, how strong the shared mental model of the system is. Efficiency and Flow finally measures the ability to complete work with minimal interruptions and wait times — the share of uninterrupted focus time, the wait time between pipeline steps, the frequency of context switches. The core principle of SPACE: select metrics from at least three of the five dimensions and never a single number, because any isolated metric will inevitably be gamed.

What DX Core 4 Measures

DX Core 4 is the youngest of the three frameworks and was created to combine the scientific depth of SPACE with the executive accessibility of DORA. It consolidates DORA and SPACE into four dimensions deliberately designed to communicate to a non-technical leadership audience as well — without losing analytical substance.

Speed captures the velocity of value delivery, measured primarily by the number of pull requests shipped per developer per week and by lead time. This dimension consistently extends the DORA throughput logic. Effectiveness measures how effective the working environment is — how smoothly developers can get their work done, prominently via the so-called Developer Experience Index, which condenses feedback loops, cognitive load, and flow state into one interpretable figure.

Quality captures the stability and maintainability of what is shipped — this is where the DORA stability metrics live on, complemented by perceived code quality and the operational burden of incidents. Business Impact finally bridges to business value: what share of engineering capacity actually flows into new, customer-facing functionality versus maintenance, unplanned work, and friction? This fourth dimension is the reason DX Core 4 works in boardroom conversations where pure DORA values are often dismissed as "technical."

The decisive conceptual contribution of DX Core 4 is three driving factors that cut across the four dimensions and explain why teams stagnate despite good DORA values: Feedback Loops (how quickly a developer learns whether a change works), Cognitive Load (how much mental effort it takes to understand and change the system), and Flow State (how often uninterrupted, focused work succeeds). These three factors are precisely what DORA cannot structurally capture — and precisely what decides top-quartile performance.

DORA, SPACE and DX Core 4 Compared Directly

The three frameworks are not competing schools but layered abstractions that build on one another. DORA provides the most robust, most easily instrumented foundation. SPACE provides the scientific breadth and protects against the classic mistake of optimizing a single number. DX Core 4 provides the business-ready synthesis that holds up in budget and strategy conversations. The table below contrasts the three models by their function, what they measure, their strength, and their structural limit.

Do not read the table as a selection aid where one framework wins. Read it as a layer model: you need all three, because each layer compensates for a weakness in the one beneath it. A pure DORA system is blind to burnout. A pure SPACE system is hard to instrument and hard to communicate to leadership. A pure DX Core 4 system without a clean DORA data foundation floats argumentatively in the air.

The Shift from Usage to Adoption

One of the most important shifts in measurement practice in 2026 concerns what counts as the success of an internal tool or platform. For a long time, usage was treated as sufficient proof: how many teams use the new CI pipeline, how many repositories sit on the internal developer platform, how high is the login rate of the new self-service portal? This logic is deceptive because forced or alternative-free usage is misread as success.

Adoption is the stricter standard. Adoption does not ask whether a tool is used but whether it is used voluntarily, repeatedly, and with measurable productivity gain — and whether developers would recommend the usage. The concise principle of this shift: adoption must be earned. A platform that has one hundred percent usage only because there is no alternative has not achieved adoption — it has merely established a mandate.

For the measurement system, this shift has concrete consequences. Complement pure usage counters with adoption signals: the share of teams that voluntarily choose an internal tool over a homegrown solution, the recommendation willingness in the developer survey, and above all the difference in DX Core 4 effectiveness between teams that do and do not use the platform. If the platform has earned adoption, this difference is measurably positive. If not, that very difference exposes the illusion a pure usage number would have concealed.

This point connects the measurement discourse directly to the DevOps maturity cluster: a mature DevOps organization is recognized not by the existence of an internal platform but by the fact that its adoption is measurably earned and shows up in the effectiveness and flow signals.

The Pragmatic Measurement Blueprint

The most common way to get this topic wrong is to attempt introducing all three frameworks fully and simultaneously. The result is an overloaded dashboard nobody interprets. The blueprint below is deliberately sequential and builds on an already established DORA foundation as described in the DORA metrics guide. Teams without a DORA baseline start there — not here.

Each step delivers value on its own. Stop after step three if capacity is lacking: you will still have a markedly better measurement system than pure DORA values. Completeness is a goal, not an entry fee.

1. 1Verify the DORA foundation: confirm that the four DORA metrics have been collected cleanly and automatically for at least four weeks. This data forms the Quality and Speed pillars of the later DX Core 4 view — without it, every further step is groundless.
2. 2Add a SPACE well-being probe: introduce a short, recurring developer survey (four to six questions, monthly) that captures Satisfaction and Well-being — satisfaction with tools, perceived friction, burnout signal. This is the cheapest leading indicator available and fills the largest DORA blind spot.
3. 3Set up the DX Core 4 effectiveness index: condense the survey plus two or three system metrics into a Developer Experience Index that explicitly reflects feedback loop speed, cognitive load, and flow state. This single composite value is the most effective single addition to DORA.
4. 4Instrument communication and flow: derive two friction signals from existing system data — the time until a pull request receives its first review, and the share of uninterrupted focus time per developer week. Both explain DORA lead time outliers the pipeline alone does not.
5. 5Anchor business impact: estimate the capacity split between new customer-facing functionality, maintenance, and unplanned work. This single number translates the entire measurement system into a language that holds up in budget and strategy conversations.
6. 6Move from usage to adoption: replace pure usage counters on every platform and tool dashboard with adoption signals — voluntary choice, recommendation willingness, measured effectiveness difference between users and non-users.
7. 7Review the triad together, not in isolation: establish a monthly review that reads DORA, the SPACE probe, and the DX Core 4 view side by side. An isolated number triggers no decision — only the pattern across all three layers does.

Anti-Patterns That Devalue the Entire System

Extending the measurement system beyond DORA also enlarges the surface for misuse. Three anti-patterns destroy the value more reliably than any measurement gap.

The first is individual evaluation. The moment SPACE satisfaction or DX Core 4 speed is tied to individuals and used in appraisals, the system collapses immediately. Developers then optimize the observed number instead of the underlying system — an effect even more damaging with the softer SPACE dimensions than with DORA, because well-being surveys are only answered honestly when they remain consequence-free for the individual. These metrics are a compass for the system, never an evaluation instrument for people.

The second is single-number condensation across everything. The Developer Experience Index is useful within the Effectiveness dimension, but the temptation to fuse it into a single overall productivity score directly contradicts the core principle of SPACE. A single number is always gameable and always context-free.

The third is context comparison without context. A platform team and a product-facing feature team naturally have different profiles across all three frameworks. The only valid comparison is a team against its own trend over time — exactly the discipline the DORA metrics guide already demands, here only across more dimensions.

How Top-Quartile Teams Emerge

The robust observation from the research behind these frameworks is not that one particular metric must be good. It is that teams in the top quartile systematically lead across multiple dimensions simultaneously — and that this combined advantage compounds to a factor of roughly four to five over the middle of the field. This advantage does not emerge from a single optimization but from addressing the supporting practices — fast feedback loops, low cognitive load, protected flow time — at the same time.

This is precisely why pure DORA optimization eventually hits a ceiling. A team can improve its deployment frequency through automation until the pipeline is fast — after that the bottleneck no longer sits in the pipeline but before it: in understanding the system, in the wait time for reviews, in fragmented focus time. Only the SPACE and DX Core 4 layers see these bottlenecks. Teams that measure only DORA keep optimizing a pipeline that long ago stopped being the constraint.

In a world where AI assistants accelerate the pure act of writing, this effect intensifies. The writing bottleneck shrinks, the comprehension and integration bottleneck grows. Exactly this divergence — DORA rising, effectiveness and flow falling — is the most valuable early warning signal a combined system can deliver, and it is structurally invisible with pure DORA values.

The practical consequence is sober: keep the DORA foundation as described in the DORA metrics guide, and use the DORA Report 2025 as the current reference for why stability and comprehension come under pressure under AI usage. Then layer the SPACE well-being probe and the DX Core 4 effectiveness index on top, anchored in your organization's DevOps maturity understanding. The advantage of top-quartile teams is no secret — it is the sum of dimensions consistently read together.

Sources & References

The frameworks, definitions, and findings referenced in this article are based on the following sources:

• The SPACE of Developer Productivity — Forsgren, Storey, Maddila, Zimmermann, Houck, Butler (ACM Queue, 2021)
• DX Core 4 — A Unified Framework for Engineering Productivity (DX / getDX): https://getdx.com/research/measuring-developer-productivity-with-the-dx-core-4
• DORA — DevOps Research and Assessment (Google): https://dora.dev/
• State of DevOps Report 2025 — DORA / Google Cloud: https://cloud.google.com/devops
• Platform Engineering 2026 — The shift from usage to adoption (industry analyses): https://platformengineering.com/