DORA, SPACE, and DevEx measure different things. Use all three.
DORA tells you how the delivery system performs, DevEx tells you why, and SPACE keeps you from measuring only what is easy to count. How I combine them to see the whole team, and the mistakes each one invites on its own.
The first metrics dashboard I built as a manager had four numbers on it: deployment frequency, lead time for changes, change failure rate, and time to restore. The DORA four. They went up and to the right for two quarters, and in the third quarter my best engineer told me she was leaving because she had not done a full day of uninterrupted work since March.
The dashboard was accurate. It was also measuring a system, and she was a person. Nothing on it could have told me what was happening to her, and I had let the green numbers stand in for the health of the team.
Three frameworks now shape how I measure a team, and the reason I use all three is that each one is blind to something the others can see.
DORA: how the delivery system performs
DORA came out of the research behind the book Accelerate. The four metrics measure the delivery pipeline from the outside: how often you ship, how long a change takes from commit to production, how often a change causes a failure, and how long it takes to recover when one does. The research tied these to organisational performance, which is why executives like them.
What DORA brings is objectivity. The numbers come from the systems, not from opinions, and they are hard to argue with in a leadership meeting. They also describe outcomes rather than activity. A team that deploys daily with a low failure rate has a healthy delivery system, whatever its story is.
The shortcomings show up when DORA is the only thing on the wall. It measures the pipeline, not the people running it, and a pipeline can look great while the humans behind it burn out. It says what is happening but never why. It can be gamed by slicing work into tiny deploys that change nothing. And it says nothing about whether you built the right thing. A team can ship the wrong feature four times a day with elite scores.
I still start here, because delivery performance is the outcome the business cares about. I just no longer stop here.
SPACE: what you are forgetting to measure
SPACE is not a set of metrics. It is a framework from a group of researchers, several of whom also worked on DORA, that says developer productivity has five dimensions: satisfaction and well being, performance, activity, communication and collaboration, and efficiency and flow. The paper's main instruction is simple. Never measure one dimension alone, and never let activity metrics such as commits or lines of code stand in for productivity.
What SPACE brings is coverage. When I put my metrics against the five dimensions, DORA fills the performance column and touches efficiency, and the other three columns are empty. That empty space is where my engineer's unfinished days were hiding. SPACE also insists on mixing what the systems record with what people report, which is the only way to see satisfaction or collaboration at all.
The shortcoming is that SPACE hands you a checklist and walks away. It does not tell you which metrics to pick, how to collect them, or how often. Teams that adopt it enthusiastically end up with twenty numbers, a dashboard nobody reads, and a survey people stop answering. And because half of it depends on self reported data, it only works on a team that trusts what the answers will be used for. On a team without that trust, the satisfaction score is a measure of politeness.
I use SPACE as an audit, not a dashboard. Once a quarter I ask whether every dimension has at least one honest signal. That question has never had a boring answer.
DevEx: why the numbers are what they are
DevEx is the most recent of the three and the most focused. Its authors argue that developer productivity comes down to three things developers experience every day: how fast their feedback loops are, how much cognitive load the work carries, and whether they can reach a state of flow. Measure those, through short regular surveys combined with workflow data, and you get leading indicators of the outcomes DORA reports later.
What DevEx brings is the why. When lead time rises, DORA shows the rise. A DevEx survey shows that the rise is because builds take twelve minutes, or because reviews wait two days, or because the codebase now has three ways to do everything. It points at friction that a manager can actually remove. It is also the only one of the three that measures what it feels like to do the work, which is where retention lives.
The shortcomings are the mirror of DORA's. DevEx leans on perception, and perception lags reality in both directions. People report that builds are slow for a month after they are fixed. It needs a steady cadence to be useful, and a survey that goes out irregularly produces noise. And on its own it is hard to connect to business outcomes, which means a CFO will nod at it and fund the DORA dashboard instead.
Why one is never enough
Each framework fails in a specific way when it is alone.
DORA alone gives you a fast pipeline and a tired team, and you find out about the team from a resignation. SPACE alone gives you a wall of numbers with no priorities. DevEx alone gives you a clear picture of friction and no proof that removing it changed anything the business can see.
Combined, they cover each other. DORA is the outcome layer: objective, lagging, the thing you report upward. DevEx is the diagnostic layer: perceptual, leading, the thing you act on. SPACE is the audit: the check that you are not quietly ignoring satisfaction or collaboration because they are hard to count.
How I run it
The rhythm on my teams looks like this. DORA metrics come from the pipeline monthly, per team, with no manual entry. A DevEx survey goes out every quarter, five minutes long, the same questions every time, covering feedback loops, cognitive load, and flow, plus one free text box. Once a quarter I lay everything out against the SPACE dimensions and look for the empty column.
Then the three get read together. If lead time goes up and the survey says reviews are slow, the fix is a review process, not a pipeline. If change failure rate goes up and the survey says cognitive load is climbing, the fix is simplification, not more testing. If every DORA number improves and satisfaction drops, I have found a team that is running hot, and the next quarter's plan has to include slowing down before it costs me someone.
What this looked like during the AI rollout
The quarter we moved to an AI first way of working was the best test of this setup I have had. DORA showed throughput up sharply and change failure rate flat, which is the story I told leadership and it was true. The DevEx survey told the rest of it. Feedback loops had gotten worse, because pull requests had tripled in size and reviews were taking days. Cognitive load was up, because people were reading large volumes of code they had not written. Flow was up for some people and down for others.
Those three signals became the guardrails: size caps on pull requests, AI assisted first pass review, and a norm that authors explain generated changes before they merge. Two quarters later, the DevEx numbers had recovered and the DORA numbers had held. Without the survey, I would have read the dashboard as a clean win and found out about the review problem when quality broke.
The SPACE audit added one more thing that quarter. Satisfaction had dipped, and the free text answers explained it: people were not sure the new tools left room for them. That is not a metric a pipeline will ever produce. It is the one that decided what I said at the next all hands.
The one line version
Measure the system with DORA, measure the experience with DevEx, and use SPACE to make sure you are not lying to yourself about coverage. A team is healthy when all three agree, and the interesting management happens when they do not.