Skip to main content

DORA & SPACE — Measuring Engineering Health

DORA measures delivery performance. SPACE measures developer productivity. Neither tells the full story alone — and neither should be used to evaluate individuals.

When to use

  • Quarterly engineering health reviews
  • Making the case for tooling or process investment
  • NOT for individual performance evaluation

Tradeoffs

  • DORA metrics can be gamed (more small deploys artificially improves frequency)
  • Activity metrics (PRs merged, commits) are vanity metrics — avoid using them alone

DORA 4 Metrics

MetricMeasuresElite threshold
Deployment FrequencyHow often you deploy to prodMultiple times/day
Lead Time for ChangesFirst commit → prod deploy< 1 hour
Change Failure Rate% of deploys causing incidents< 5%
Time to RestoreMTTR when an incident occurs< 1 hour

SPACE Dimensions

DimensionWhat it captures
SatisfactionDeveloper wellbeing, burnout risk
PerformanceOutcomes delivered, quality
ActivityCommits, PRs, reviews (context-dependent)
Communication/CollaborationKnowledge sharing, unblocking
EfficiencyFlow state, interruptions, toil

// DORA metrics — SQL/Prometheus patterns

// Deployment Frequency: deploys per day
// SELECT DATE(deployed_at), COUNT(*) AS deploys
// FROM deployments
// WHERE env = 'prod'
// GROUP BY DATE(deployed_at)

// Lead Time: avg minutes from first commit to deploy
// SELECT AVG(TIMESTAMPDIFF(MINUTE, first_commit_at, deployed_at))
// FROM deployments WHERE env = 'prod'

// Change Failure Rate: failed deploys / total deploys
// SELECT
// SUM(CASE WHEN caused_incident THEN 1 ELSE 0 END) * 100.0
// / COUNT(*) AS failure_rate_pct
// FROM deployments WHERE env = 'prod'

// Time to Restore: avg minutes incident open
// SELECT AVG(TIMESTAMPDIFF(MINUTE, opened_at, resolved_at))
// FROM incidents

Gotcha: Never use DORA metrics to evaluate individual engineers. They measure team and system health. An engineer in a slow org with manual deploys will look worse than an engineer in a fast org with CD — even if they're better.