top of page

The SPACE Framework — Engineering Metrics & DORA, Part 6

  • Shawn West
  • Jul 28
  • 5 min read

Updated: Aug 20

Engineering Metrics & DORA · Part 6

DORA tells you how fast and safely a team delivers — but a team can hit great DORA numbers while quietly burning out, and that shows up nowhere in the four metrics. SPACE is the wider lens: satisfaction, performance, activity, communication, and efficiency. This walks through using it to see the parts of team health DORA misses — without turning it into surveillance, which is the fastest way to make any metric lie.

a separate framework. Five dimensions of productivity. More holistic; harder to measure.

Before you start

  • A working set of delivery metrics from Parts 1-5, or at least an honest lead time. SPACE is a complement to those numbers, not a substitute, and it is hard to read the human dimensions without the delivery picture beside them.

  • A way to survey a team and keep the responses confidential. Two of the five dimensions are only reachable by asking people, and a survey people believe is attributable returns the answers they think you want.

  • A team that has been together long enough to have a baseline. A first survey tells you very little on its own; the value is the trend, which means committing to run it again.

  • Genuine willingness to act on an uncomfortable result. Running a satisfaction survey and doing nothing is worse than not running one — it teaches the team that answering honestly changes nothing.

Step 1: The Five Dimensions (10 min)

  • S — Satisfaction (developer experience)

  • P — Performance (outcomes)

  • A — Activity (commits, PRs)

  • C — Communication and Collaboration

  • E — Efficiency / Flow

Productivity is multi-faceted. Single metrics don't capture it.

Step 2: Why SPACE Over DORA Alone (10 min)

DORA is great. But it misses:

  • Are engineers happy? Stressed?

  • Is the work meaningful?

  • How much wait time vs. real work?

  • Does collaboration help or burn?

SPACE asks broader questions.

Step 3: Satisfaction (Surveys) (15 min)

Quarterly anonymous:

  • "I have what I need to do my job well" (1-5)

  • "Code review feedback is useful" (1-5)

  • "I find the work meaningful" (1-5)

  • "I'm planning to be here in 12 months" (1-5)

  • Open-ended: "What's frustrating?"

Watch trends. Act on patterns.

If 30% of engineers say "tooling is the worst": real signal.

Step 4: Performance (Outcomes) (10 min)

Beyond DORA:

  • Features shipped vs. roadmap

  • Customer-visible quality (NPS, support tickets)

  • Business metrics tied to engineering work

  • Goals achieved vs. set

Performance ties engineering to business. Without this: optimizing in a vacuum.

Step 5: Activity (Carefully) (15 min)

Counts:

  • Commits / day

  • PRs / week

  • Reviews done

Easy to abuse. Don't rank engineers by commit count.

Useful at:

  • Team level (trend over time)

  • Aggregate patterns

  • Outliers (someone way below team norm; possibly stuck)

Never as performance evaluation. Goodhart's Law.

Step 6: Communication and Collaboration (15 min)

Hard to measure quantitatively. Proxies:

  • Cross-team PRs (collaboration sign)

  • Question response time in Slack

  • Knowledge sharing (docs, demos)

  • Onboarding time for new hires

  • Sentiment in retros

Or qualitative:

  • 1:1s

  • Retros

  • Skip-level chats

Mostly qualitative; data supports.

Step 7: Efficiency / Flow (15 min)

How much time is real work vs. interruption?

  • Time-in-meetings vs. heads-down (calendar analysis)

  • WIP limits (work in progress)

  • Time between standups / interruptions

Engineers in flow state ship. Constant context-switch tanks output.

Step 8: Multiple Dimensions, Not One (10 min)

Don't roll up SPACE into "the SPACE number."

The whole point: look at all five. Trade-offs visible.

A team might:

  • Score elite on DORA

  • But scores low on satisfaction

  • That's a burnout warning

DORA alone wouldn't catch it.

Step 9: Per-Team, Trend Over Time (10 min)

Like DORA:

  • Per-team

  • Trend month-over-month

  • Compare to your own past, not other teams

External comparison is rarely useful. Internal trend is.

Step 10: Beware Surveillance (10 min)

SPACE done badly = surveillance:

  • Tracking every commit

  • Monitoring meeting time

  • Engineer-level efficiency reports

People hate it. Quit.

SPACE done well:

  • Team-level

  • Anonymous where qualitative

  • Used to improve, not punish

  • Engineers see their own data

The difference is everything.

The five dimensions, and how each one gets abused

Dimension

What it captures

The failure mode

Satisfaction and well-being

How fulfilled and healthy people are in the work — with the team, the tools, the culture

Surveyed once, never repeated, never acted on. Or attributed, which quietly turns it into a performance review

Performance

Whether the work achieved its intended outcome

Substituting output for outcome, because output is easier to count. Shipped features are not the same as an effect on users

Activity

The volume of visible engineering actions

The most dangerous of the five. Counting commits, PRs or tickets per person recreates every anti-pattern in Part 7. Activity is context, never a score

Communication and collaboration

How well work moves between people — review, handoff, discoverability

Measured by meeting hours or message counts, which rewards noise. The signal is whether people can find what they need and get unblocked

Efficiency and flow

How much uninterrupted forward progress is sustainable

Read as a mandate to eliminate all interruption, including the collaboration the previous dimension depends on

SPACE is not DORA's replacement

It is worth being precise about this, because the two get conflated in decks and the conflation causes bad decisions. SPACE is a separate framework, published in ACM Queue in 2021 by researchers from Microsoft Research, GitHub and the University of Victoria. Nicole Forsgren co-authored both it and the DORA research, which is why people assume a lineage — but SPACE does not supersede the delivery metrics and does not replace them.

They answer different questions. The delivery metrics describe how change moves through your system. SPACE describes the experience and effectiveness of the people doing the work, including things a deploy pipeline cannot see. The authors' point is the one worth carrying: productivity "cannot be measured by a single metric or dimension" — which is also the argument against picking your favourite SPACE dimension and treating it as the new single number.

The practical rule from the paper's framing: use more than one dimension, and never one alone. A team can look strong on delivery and be quietly burning out, which is exactly the case the delivery metrics are blind to.

You're done when

  • You are measuring at least two dimensions, and can say why those two for this team — not five because the acronym has five letters.

  • Your satisfaction data comes from a confidential survey you have committed to repeating, and you can name one change you made because of what it said.

  • No dimension is reported per-person. If any of your SPACE numbers can be traced to an individual, you have built surveillance and the data will degrade as soon as people notice.

What You Just Did

SPACE: five dimensions, why broader than DORA, satisfaction, performance, activity caveats, collaboration, efficiency, multi-dimensional, trends, no surveillance. Modern engineering productivity.

Common Failure Modes

Roll up to a single number. Loses the dimensions.

Compare engineers by Activity. Gaming; resentment.

Surveil individuals. Quit risk.

Skip Satisfaction surveys. Miss burnout.

Track without action. Numbers; no change.

Sources

Continue the Engineering Metrics & DORA path

Part of the Engineering Metrics & DORA learning path.

bottom of page