SPACE & DevEx

The problem

When a company grows and delivery doesn't speed up with it, someone asks for productivity numbers, and the numbers that are easiest to get count activity: commits, pull requests, lines of code, tickets closed. The tools already record them, which is their appeal, but they measure motion rather than progress. They climb when work is chopped into small pieces, when code is generated or copied, or when people put in long hours to get around a slow system, and they drop for the work that keeps a team going: reviewing, pairing with new hires, writing design documents, being on call. Ranked per person on a leaderboard, they also teach people quickly what moves their rank. The questions that matter stay unanswered: what slows the engineers down, how they are doing, and whether customers get better software sooner. Delivery metrics such as DORA's help with the last question, but they describe a team's pipeline, not the daily friction behind it.

How it works

Two frameworks, written by overlapping groups of researchers and published in ACM Queue two years apart, answer the question in complementary ways. SPACE describes what developer productivity is made of, so that a team can choose a balanced set of measures. DevEx looks at productivity from the developer's side and points to the friction worth removing.

SPACE (2021)

The SPACE of Developer Productivity by Nicole Forsgren (then at GitHub), Margaret-Anne Storey (University of Victoria), and Chandra Maddila, Thomas Zimmermann, Brian Houck and Jenna Butler (Microsoft) appeared in ACM Queue, vol. 19, no. 1, in 2021. It opens by taking apart five common beliefs: that productivity is all about developer activity, that it is only about individual performance, that one metric can capture it, that productivity measures are only for managers, and that it is only about engineering systems and tools. It then names five dimensions (descriptions paraphrased):

The paper's advice on using the dimensions, paraphrased:

• Several dimensions at once. Pick metrics from at least three dimensions, and don't pad the set with more of the same kind: commits, pull requests and coding time are all activity. Metrics shape behaviour, so a set with some tension in it (more speed against fewer bugs reaching customers) keeps any one of them from being optimised alone. Keep it to a handful; a long list of targets confuses people and wears them down.
• Perception next to system data. Include at least one perceptual measure, such as survey answers; what people experience often shows what instrumentation can't. Ask people about their own experience (did you feel productive, could you focus) rather than asking them to rate their team.
• Levels and privacy. A metric can describe one person, a team or group, or the whole system. Report anonymous aggregates at the team or group level (the paper notes that reporting individual productivity isn't legal in some countries); individual data is useful to the developer it describes, not to a ranking.
• Biases. Check what could skew the numbers: normalising over a long period penalises people who took parental leave, and some cultures answer surveys systematically higher or lower than others, so their scores have different baselines and shouldn't be compared directly.

The paper links efficiency and flow at the team and system level to value-stream mapping, and it cites DORA's deployment frequency and lead time as examples of flow measures.

DevEx (2023)

DevEx: What Actually Drives Productivity by Abi Noda (DX), Margaret-Anne Storey (University of Victoria), Nicole Forsgren (Microsoft Research) and Michaela Greiler (DX) appeared in ACM Queue, vol. 21, no. 2, in 2023. It treats developer experience as what developers live through at work, from their feelings about it to the friction they hit every day, and it builds on the authors' earlier research, which found more than 25 sociotechnical factors behind it. The paper condenses them into three dimensions:

• Feedback loops: how fast and how well tools and people respond to what a developer does, from builds and tests to code review and deployment. Slow loops make people wait or switch tasks.
• Cognitive load: the mental effort a task demands. Poorly documented code and systems and a growing pile of tools push it up.
• Flow state: being fully absorbed in focused work. Interruptions, unplanned work and scattered meetings break it.

Tools are only part of the story: the paper reports that human factors, such as clear project goals and feeling psychologically safe in the team, have a large effect too.

For measurement, the paper pairs two kinds of data for each dimension: developers' perceptions (their attitudes and opinions, mostly from surveys) and their workflows (data from systems and processes), because each kind misses what the other sees. Code review can look fast in the data and still feel disruptive if it keeps interrupting focused work. Above these sit a few KPIs, the north-star outcomes that improvements are meant to move, such as productivity, satisfaction, engagement and retention. They keep a local fix honest: cutting meetings can add focus time and still hurt collaboration and overall satisfaction. On surveys, the paper recommends questions built on well-defined concepts and tested in interviews, results broken down by team and by persona (role, tenure, seniority) rather than read as company-wide averages, comparison with benchmarks for context, short transactional surveys at specific moments in the workflow, and follow-up after every survey, because participation drops when people see nothing happen. For most organisations it suggests running the survey every quarter or every six months.

How they relate to each other and to DORA

• SPACE chooses the measures; DevEx finds the friction. Acme uses SPACE to pick a balanced scorecard across five dimensions and reads the same survey through DevEx's three dimensions to decide what to fix. Both papers ask for perception and system data side by side.
• DORA measures delivery outcomes. DORA's metrics describe a service's delivery process: throughput (change lead time, deployment frequency, failed deployment recovery time) and instability (change fail rate, deployment rework rate). They show whether delivery got better, not how the work feels or where developers lose time, so many organisations read them next to a SPACE or DevEx survey. DORA's 2025 guide to measurement frameworks (Sarah D'Angelo, Ambar Murillo, Sarah Inman and Kevin M. Storer) suggests starting from the decision the numbers should inform, weighing self-reported against log-based data (self-reports capture experience but are hard to standardise and compare across teams; logs scale but need instrumentation and are less objective than they look), and combining frameworks when one alone can't answer the question.
• Combined frameworks. DX, the company Abi Noda founded, publishes the DX Core 4 (by Abi Noda, Laura Tacho, Margaret-Anne Storey and Michaela Greiler), which folds DORA, SPACE and DevEx into four dimensions: speed, effectiveness, quality and business impact. Its own guidance warns that its throughput metric, diffs per engineer, has to be balanced by experience measures and never tied to targets or rewards.
• Goodhart's law applies to all of them: once a measure becomes a target, it stops being a good measure. The idea is named after the economist Charles Goodhart, who described it for monetary policy in 1975; the wording most people quote appeared in a 1997 paper by the anthropologist Marilyn Strathern.

Putting it into practice

1. Start from the question and the decision. Acme's CTO wanted to know why 15 more engineers brought no speed-up; the decision behind it was where to invest the next quarter. Write both down before choosing a metric.
2. Choose a handful of measures across at least three SPACE dimensions, with at least one from a survey, reported per team. Acme took one survey measure and one system measure for each of the five (below) and agreed in advance that nothing would be reported per person.
3. Run a short, anonymous survey on a fixed rhythm. Acme runs it every quarter and keeps it to about ten minutes. The questions ask about each person's own last few weeks (how long did you wait for CI, how many hours could you focus) and were tried out on a few engineers first. Results are shown per team and per role only where at least five people answered, and smaller groups are merged (Acme's rule). Track the response rate: 52 of 60 answered in Q2.
4. Pull the system data you already have. CI run times from the CI system (GitHub Actions, GitLab CI or Jenkins, say), review waits from the Git host, deploys from the deploy log, night pages from the paging tool, and meeting load from calendar data aggregated per team. Write down how each number is computed, and keep it the same from quarter to quarter.
5. Read the answers through DevEx. For each dimension, find the biggest friction and check it against the system data. Acme's survey named slow CI (the top pain for 31 of 52), the five tools a new service needs (hard for 27 of 52) and scattered meetings (1.8 hours of focus a day), and the CI data agreed: 38 minutes a run.
6. Fix a few things, with owners. The platform team cut CI to 12 minutes with test sharding and a build cache and made the golden path in Launchpad the way to start a service, and the engineering managers agreed on meeting-free mornings.
7. Close the loop and measure again. Acme shared each team's results within three weeks, said what would change and when, and compared the next quarter with this one (below).
8. Watch the counterweights. When a change helps one measure, check the ones it could hurt. Meeting-free mornings could make help harder to get, so Acme watched ease of getting help and the wait for a first review; faster CI could let more failures through, so it watched the change fail rate.

Acme's measures, with the Q2 2026 baseline (the example's own numbers, not research findings):

Quarter by quarter (the example's own numbers):

Where it fits

• DORA metrics measure what comes out of the delivery pipeline; SPACE and DevEx measure the experience and productivity behind it. Read them together: Acme's deploys went from 42 to 49 a week after CI got faster, and the change fail rate showed that stability held.
• Platform as a product needs exactly this kind of data. The developer survey is how a platform team learns what hurts, and DevEx measures such as CI wait, setup effort and focus time show whether the platform helped.
• Golden paths are a direct answer to cognitive load: Acme's five tools for a new service became one template.
• Team Topologies uses a team's cognitive load as a limit when drawing team boundaries; DevEx asks about the same load from each developer's side.
• Eliminating toil frees time and attention: repetitive manual work and night pages show up as lost flow and poorer well-being.
• Continuous delivery and trunk-based development shorten feedback loops with fast CI and small changes that are quick to review.
• The Three Ways describe flow, feedback and continual learning; SPACE's efficiency and flow and DevEx's feedback loops are ways to measure the first two.
• Value stream mapping is where SPACE itself points for efficiency and flow at the team and system level: it shows where work waits.
• CALMS counts measurement among the things to assess in a DevOps adoption; SPACE and DevEx fill in that measurement for the developer side.

When to use it

• When leadership asks for productivity numbers. A SPACE scorecard gives an answer that doesn't rank people, and a DevEx reading of the same survey turns it into a list of things to fix.
• Before and after an investment in tooling, a platform or a way of working. Faster CI, a golden path or a new review practice should show up in both the answers and the system data; if only one of them moves, look closer.
• From a few teams up. In a single team of five or six, a retrospective gives the same signal for less effort, and answers can't stay anonymous when a result covers only a handful of people.
• Not for performance reviews or pay. Once survey answers or activity counts feed individual evaluations, people stop answering honestly and start working the numbers.
• Agree on the rules first where privacy law or employee representatives have a say. SPACE notes that reporting individual productivity isn't legal in some countries. Settle what is collected, how it is aggregated and who sees it before the first survey goes out.
• Only when someone will act on the results. A survey costs every engineer's time each quarter (about ten minutes times 60 people at Acme), and the follow-up needs an owner. If nobody will act, the survey teaches people that answering is pointless.

Common pitfalls

• Ranking individuals. Per-person leaderboards and survey scores punish the people who review, pair, mentor and carry the pager, invite gaming and end honest answers. Keep answers anonymous, report per team with a minimum group size (Acme's is five), and leave individual data to the person it describes.
• One number for productivity. An index that averages everything into one score, like the 72 in Acme's board deck, hides which dimension moved and why, and invites optimising the index. Show the dimensions side by side and talk about what changed.
• Surveys with no action. When results disappear, participation falls (the search team went from 6 answers to 2), and below the minimum group size a team gets no result at all. Share results within weeks, commit to one or two fixes, and say in the next survey what changed.
• Comparing teams that do different work. Payments waits for PCI approvals and the mobile app for app store review, so their scores reflect the work as much as the team. Compare each team with its own past, and use benchmarks for context only.
• Only survey data, or only system data. Acme's CI chart said 12 minutes while the answers said flaky tests forced re-runs; a survey alone, on the other hand, can't say how long CI takes or where the wait sits. Read each kind against the other and dig in where they disagree.
• Turning measures into targets. A target on commits, deploys or a satisfaction score invites moving the number instead of the work (Goodhart's law). Set goals on the friction to remove, and use the measures to check whether it went away.
• Measuring too much. Long surveys and dashboards with dozens of charts tire people and bury the signal. Keep a handful of measures and a survey people can finish in about ten minutes.
• Ignoring bias and context. A quarter heavy with incidents or a reorganisation, long leave, or a group that answers surveys more modestly will move the numbers. Read them with their context, and keep the questions and definitions stable so the trend means something.