Skip to main content

Measuring developer experience: DORA + SPACE that matter

Tommy Ryan
  • devex
  • metrics
  • leadership
  • culture
Minimal instruments and labeled blocks suggesting DORA and SPACE measurement.

If you measure lines of code, you’ll get lines of code. Measure outcomes instead.

Developer experience (DevEx) is the set of friction points and feedback loops that determine how fast code becomes customer value without exploding reliability. You don’t improve DevEx with vibes. You improve it by choosing a few honest measures, baselining them, and then running boring experiments that move the numbers.

DORA and SPACE give you a shared language to do this. DORA focuses on delivery outcomes; SPACE widens the lens to include human factors. Together they keep you from optimizing for PR confetti while production burns—or pampering happiness while throughput craters.

Why measure DevEx at all?

  • Because throughput is limited by cognitive load, not clock time. Long feedback cycles, flaky tests, and mystery deployments melt attention.
  • Because teams overestimate how “fast” they are when they don’t measure. Feelings are seasonal; metrics are falsifiable.
  • Because when you can show a 40% drop in lead time and stable change failure rate, you can argue for platform investment with a straight face.

DORA, with the sharp edges exposed

  • Lead time for changes: from first commit (or PR open) to production. Watch p50 and p90; the tail is where pain hides.
  • Deployment frequency: how often prod changes. Spiky charts mean batchy work—usually a smell.
  • Change failure rate: percent of deploys that cause customer‑visible issues, hotfixes, or rollbacks. Define “failure” up front or you’ll litigate after the fact.
  • MTTR: time to restore service after a failure. Pair this with incident count or severity so you don’t “improve” MTTR by redefining incidents.

DORA is useful because it is close to customer impact and relatively hard to fake. It also pushes you toward small batches, good testing, and automated deployments—things that compound.

SPACE, without turning it into a mood ring

  • Satisfaction & well‑being: pulse surveys about tools, docs, autonomy, cognitive load. Short and frequent beats long and ignored.
  • Performance: outcomes achieved, not hours spent. Tie back to DORA and product metrics.
  • Activity: commits, reviews, builds. Treat as diagnostic only; optimize these and you’ll get beautiful busywork.
  • Communication & collaboration: review latency, cross‑team handoffs, clarity of ownership.
  • Efficiency & flow: time in review, CI durations, local env setup time, flaky test counts.

SPACE rounds off the edges DORA misses. Burned‑out teams can hit DORA targets for a quarter—then quit. Conversely, very “satisfied” teams can drift if there’s no outcome tether. Use both.

Baselines before bets

  • Instrument for two to four weeks without changing anything material. Record p50/p90, not just averages. Capture variance by team or repo if your org is heterogeneous.
  • Write down your exact definitions (what counts as a deploy, a failure, a restore). You’ll forget in three months.
  • Only then set targets and pick two or three experiments you believe will move a DORA and a SPACE dimension together.

Example: “Cut PR review latency p50 from 18h to 6h while keeping change failure rate ≤ 15%.” Bets might include smaller PR guidelines, review SLAs, and auto‑merge after green + two approvals.

Instrumentation that doesn’t creep people out

  • Collect from systems, not spies: CI/CD, Git host, incident tool, feature flags, support system.
  • Prefer team‑level dashboards to individual leaderboards. If you must drill down, do it for coaching or incident analysis—not compensation.
  • Anonymize survey data and publish question banks and response rates. If people don’t trust the process, the data is noise.

Cadence that sticks

  • Weekly: glance at DORA trends, CI duration, flaky test counts. Triage and fix flakiest tests like production bugs.
  • Bi‑weekly: review PR size, review latency, queue lengths. Nudge behaviors (smaller changes, earlier reviews).
  • Monthly: SPACE pulse (5–7 questions), decide whether to continue, kill, or scale experiments.
  • Quarterly: reset targets with fresh baselines; write an ADR‑style note on what worked and what didn’t.

A compact DevEx dashboard (MVP)

  • Lead time p50/p90
  • Deployment frequency (per week)
  • Change failure rate
  • MTTR
  • CI duration p50/p90 and flaky test count
  • PR review latency p50/p90
  • SPACE pulse: satisfaction with tools/docs/autonomy (1–5)

If it doesn’t fit on one screen, it won’t fit in anyone’s head. Link to drill‑downs for the curious.

Smells and anti‑patterns

  • Loc‑per‑dev, PRs‑per‑dev, or hours‑in‑IDE: you’ll get more, none of it valuable.
  • Weekly comparisons across teams with different domains: punishes platform teams and socio‑technical complexity.
  • “We’re elite now because the book said so.” Pick targets that reflect your domain (regulated, mobile, embedded, etc.).
  • Green dashboards with red customers. Pair DevEx with product health: latency, error rate, and user‑visible outcomes.

The point is not to win at metrics. The point is to ship valuable, reliable software with humans who want to come back tomorrow. Use DORA + SPACE to keep both halves true.

Start here

  • DORA: Lead time, deployment frequency, change failure rate, MTTR.
  • SPACE: Satisfaction, Performance, Activity, Communication, Efficiency.
  • Baselines before bets: Know where you are before you celebrate.

Anti‑gaming tips

  • Use medians, not averages.
  • Look at trends, not weeks.
  • Pair quantitative with qualitative (surveys, interviews).

If the numbers move and quality holds, you’re doing it right.