DevEx measurement frameworks

SPACE, the Developer Experience Index, and DX Core 4 measure developer experience and productivity. They were developed primarily for internal engineering organisations, but some DevRel teams use their methods to evaluate external developer products.

SPACE (2021)

The SPACE framework was published in 2021 by Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler: a research collaboration between Microsoft Research, GitHub Next, the University of Victoria, and others. It is the most widely cited modern framework for developer productivity.

SPACE stands for five dimensions:

LetterDimensionExample measures
SSatisfaction and well-beingNPS, burnout surveys, engagement scores
PPerformanceCode quality, delivery against goals, customer impact
AActivityCommits, PRs merged, deployments
CCommunication and collaborationCode review effectiveness, doc reuse, knowledge sharing
EEfficiency and flowFocus time, interruption rate, lead time

The framework’s central claim is that no single dimension is enough, and that “productivity” measured along one dimension alone is at best misleading and at worst harmful. Measuring activity alone rewards busy-looking developers; measuring satisfaction alone rewards comfortable teams that ship slowly.

SPACE requires:

  • A mix of perceptual (survey-based) and behavioural (system-derived) measures.
  • Measurement at the team level, not the individual level (to avoid micro-management failure modes).
  • Triangulation between dimensions: improvements in one should not come at the cost of degradation in another.

Why it matters for DevRel. DevRel teams building developer products (internal or external) increasingly use SPACE-derived measurements to assess developer productivity alongside product engagement.

DXI: Developer Experience Index (2023+)

The Developer Experience Index (DXI) is a composite metric developed by Abi Noda’s team at getdx.com (DX), based on a research dataset spanning over 800 organisations and 4 million observations. It builds on SPACE but distils it into a more actionable composite index.

The DXI is calculated from 14 standardised survey items covering areas including:

  • Code quality and codebase health.
  • Onboarding friction.
  • Build, test, and CI/CD speed.
  • Focus time and interruption load.
  • Documentation quality.
  • Tooling adequacy.
  • Deployment confidence.

Each item is scored on a Likert scale; the composite is a 0 to 100 number. The headline empirical claim, reported by DX from its dataset: a one-point improvement in DXI score correlates with roughly 13 minutes of developer time saved per developer per week, or about 10 hours per year per developer.

For a 500-engineer organisation, a 5-point DXI improvement therefore translates to roughly 25,000 hours of recovered engineering time annually. This calculation converts a change in the composite score into an estimate of engineering time.

Why it matters for DevRel. DXI measures aspects of experience that external developers encounter during evaluation and use, and expresses the resulting estimates in financial terms.

DX Core 4 (2024)

The DX Core 4 combines three previously distinct frameworks:

  • DORA metrics (Deployment Frequency, Lead Time for Changes, Mean Time to Restore, Change Failure Rate): the four key software delivery metrics from Forsgren’s Accelerate.
  • SPACE. The dimensions of productivity.
  • DXI. The perceptual measurement.

DX Core 4 organises measurement around four balanced dimensions:

  1. Speed. How fast does the team deliver? (DORA-flavoured.)
  2. Effectiveness. Are developers able to do their best work? (DXI-flavoured.)
  3. Quality. Are we delivering reliably? (Change failure rate, defect rate.)
  4. Impact. Is the work moving the business? (Customer-facing outcomes.)

The framework is designed to be the unifying measurement layer for engineering organisations and is increasingly adopted by DevEx and platform-engineering teams.

How these relate to DevRel

For external developer-product DevRel teams, these frameworks have three implications:

  1. They give DevRel a productivity vocabulary that pairs with strategy frameworks. AAARRRP can define Activation as a goal, while DXI can connect activation to measurable factors such as TTFHW and documentation quality.
  2. They support investment in docs, SDKs, and onboarding as productivity work. If a product saves customer developers measurable time, that estimate can inform budget decisions.
  3. They distinguish internal from external DevEx. Platform engineering or DPE usually owns internal engineering productivity. DevRel may own or influence the experience of external developers using the product; teams should specify which scope a metric covers.

Survey design matters

All three frameworks rely heavily on survey-based measurement. Their methods imply several implementation choices:

  • Run the same surveys every quarter. The year-over-year trend is more informative than one absolute number.
  • Aggregate to team or product area, never to individual developer. Individual-level measurement creates a performance-monitoring or surveillance risk.
  • Pair perception data with behavioural data. Divergence between reported satisfaction and delivery data requires investigation rather than an inference from either measure alone.
  • Respond visibly. Surveys that produce no action degrade response rate within two cycles.

When these frameworks are not useful

  • For very small teams (under 20 developers). The instrumentation overhead exceeds the value.
  • For teams where the productivity bottleneck is upstream (poor product strategy, organisational politics). No framework will fix that.
  • As a hiring or performance-review lens for individual contributors. Designed for team-level use.

Primary sources

  • Forsgren, Storey, Maddila, Zimmermann, Houck, Butler, “The SPACE of Developer Productivity,” Communications of the ACM, 2021.
  • Abi Noda et al., The State of Developer Experience report (DX / getdx.com, multiple editions).
  • Accelerate (Forsgren, Humble, Kim), 2018: the canonical DORA reference.
  • DX, “DX Core 4 explained,” getdx.com, 2024.
  • Atlassian, State of Developer Experience Report 2025.

See also