Can We Measure Developer Productivity?
summary
Asserts that productivity is measurable but only useful when tied to purpose and owned by teams, not used for performance reviews; recommends the DORA four metrics (lead time, deployment frequency, change failure rate, time to restore), the SPACE framework for choosing tailored metrics, and techniques like mutation testing and continuous delivery pipelines to reveal bottlenecks; warns that fixed targets (eg. an 80% coverage goal) trigger gaming via Goodhart’s law; case studies show clearer roles and better onboarding actually move the needle.
AI-written summary · about
chapters (7)
- 0:00Introduction and context
- 12:21The dangers of metrics
- 16:03DORA metrics and bottlenecks
- 24:10Empirical science challenges
- 26:49The SPACE framework
- 31:10Critique of McKinsey paper
- 43:23Conclusion and Q&A
related talks
33mMeasuring Developer Productivity: the good, the bad and the data
43mMeasuring Developer Productivity: The Good, the Bad and the Data
31mHow Do You Measure Devel...
43mThe Past, Present and Future of Developer Productivity Theories and Metrics
11mWhat does 'productivity' actually mean for developers?
33mBeyond developer productivity: what's next?
18mFrom developer productivity to engineering impact
26mWhere we’re going wrong with developer productivity