The DORA metrics (from the DevOps Research and Assessment program / Accelerate book) measure software delivery performance: Deployment Frequency (how often you ship), Lead Time for Changes (commit to production), Change Failure Rate (% of deployments causing a failure), and Time to Restore Service (how fast you recover from incidents). The first two measure throughput, the last two stability — and research shows elite teams excel at both simultaneously, debunking the myth that speed and stability trade off.
2 / 5
What does lead time for changes measure?
Lead time for changes measures the elapsed time from when code is committed to when it is successfully running in production. It captures the efficiency of your entire delivery pipeline: review, CI, testing, staging, and deployment. Short lead times (elite teams: under a day) mean fast feedback, smaller and safer changes, and quicker value delivery. Long lead times indicate pipeline friction — slow tests, manual approvals, batching. It is distinct from cycle time (which may start at work-begin) by anchoring specifically on commit-to-production.
3 / 5
What is the SPACE framework for developer productivity?
The SPACE framework (Forsgren et al.) was created to counter the misuse of single, gameable metrics like lines of code or commit counts. It argues developer productivity is multidimensional: Satisfaction and well-being, Performance (outcomes/quality), Activity (counts of actions), Communication and collaboration, and Efficiency and flow. The guidance is to measure across multiple dimensions and combine perceptual (survey) data with system data — never reducing productivity to one number, which inevitably gets gamed and harms morale.
4 / 5
What is "cognitive load" in the context of developer experience?
Cognitive load is the amount of working memory and mental effort a task demands. In developer experience, high extraneous cognitive load — caused by having to understand too many systems, constant context switching, confusing tooling, and undocumented processes — directly harms productivity and satisfaction. Team Topologies argues teams should be sized and scoped so the systems they own fit within their cognitive capacity. Platform engineering and golden paths exist precisely to reduce the cognitive load on product teams by hiding infrastructure complexity behind self-serve abstractions.
5 / 5
Why does measuring change failure rate alongside deployment frequency matter?
Measuring throughput (deployment frequency) without stability (change failure rate) is dangerous — you could ship constantly while breaking production constantly. The DORA insight is that elite teams achieve both: they deploy frequently and maintain low change failure rates, because small, frequent, well-tested changes are inherently safer than large, infrequent ones. Pairing the metrics prevents gaming: optimizing deploy frequency alone might encourage rushing, but the failure-rate guardrail keeps the focus on sustainable, safe velocity rather than reckless speed.