Why DORA Alone Is Insufficient
Imagine a team with excellent DORA scores: they deploy 30 times a day with a 2% change failure rate and sub-hour MTTR. But to achieve this, engineers work 70-hour weeks, are constantly on-call, skip lunch to monitor deployments, and report high burnout in exit interviews. Is that a success?
No. DORA measures the output of the system. It says nothing about the human cost of producing that output, the efficiency of the workflow, or whether the people doing the work are sustainable contributors or burning out.
This is the gap the SPACE framework fills.
The Five Dimensions of SPACE
SPACE was developed by researchers from GitHub, Microsoft Research, and the University of Victoria, published in 2021. It provides a structured way to think about developer productivity that goes beyond counting commits or measuring pipeline speed.
The key insight of SPACE is that productivity is multidimensional — you cannot capture it with a single number, and any single metric can be gamed or misinterpreted.
-
S — Satisfaction and well-being: Are developers satisfied with their work, their tools, and their team? Do they feel burnt out? Do they feel their work is meaningful? This is measured primarily through surveys — tools like the Developer Experience (DevEx) survey or simple quarterly pulse checks. A platform team should track whether their tools increase or decrease satisfaction scores.
-
P — Performance: What are the outcomes and impact of the work? This is where DORA metrics live, but it also includes things like customer adoption of features, reliability of services, and code quality indicators. Performance is about outcomes, not output.
-
A — Activity: What are developers actually doing? This includes measurable signals like number of commits, pull requests opened and reviewed, documentation written, and incidents resolved. Critical warning: Activity metrics are the most easily gamed dimension. A developer can open 50 tiny PRs to look productive while delivering zero value. Activity should only be used as a signal in combination with other dimensions, never in isolation.
-
C — Communication and collaboration: How effectively do teams share knowledge and coordinate work? Are code reviews happening quickly? Is documentation being written and read? Are cross-team dependencies being resolved efficiently? A platform that makes it easy to share runbooks, discover existing services, and get help from other teams improves this dimension.
-
E — Efficiency and flow: Can developers get into a state of deep, focused work? How often are they interrupted by alerts, meetings, or waiting for slow systems? How long does a developer spend waiting for a CI build to give them feedback? A platform that reduces build times from 20 minutes to 2 minutes directly improves flow — developers can stay in context rather than context-switching to something else while they wait.
What Platform Teams Should Focus On
Of the five dimensions, platform teams have the most direct influence on Efficiency and Flow and Satisfaction. Reducing build times, eliminating manual approval steps, providing self-service tooling, and writing clear documentation all improve these dimensions measurably.
A useful practice: run a developer survey before launching a major platform feature, and again 90 days after. Ask specific questions about the dimensions you expected to improve. The delta is your evidence.
A common interview question is: "How do you measure developer productivity?" The trap is to answer with activity metrics (commits, PRs, lines of code). A strong answer names the SPACE framework, explains that productivity is multidimensional, and specifically calls out that activity metrics alone are misleading and easily gamed. Then pivot to which dimensions matter most for the role you're interviewing for.