Measuring Developer Productivity: The Good, the Bad and the Data
summary
Argues that productivity must measure business impacts not code volume and combines quantitative metrics with qualitative surveys; endorses DORA for deployment cadence but promotes Thoughtworks’ EEBO and SPACE-style mixes to link tech to outcomes. Claims surprising correlations: documentation improvements → ~12× performance, shorter code reviews → ~50% better delivery metrics, generative culture → ~30% org boost and user focus → ~40% gain. Recommends automation, flexible cloud infra, fair work distribution and developer‑experience templates; AI shows unclear group benefits.
AI-written summary · about
chapters (23)
- 0:00Introduction
- 1:12Thoughtworks and conference context
- 3:21Agenda and definition
- 4:31Productivity elements
- 7:00Good practices for measuring
- 8:32Qualitative vs quantitative metrics
- 10:04Team-level productivity focus
- 12:15Bad practices in measuring
- 15:54Vanity metrics consequences
- 20:05Generative culture data
- 21:58User focus importance
- 23:29Code review speed correlation
- 24:57Microservices and team performance
- 25:39AI's limited impact
- 26:25Job satisfaction measures
- 27:31Documentation and trunk-based dev
- 27:56Reliability and operational improvements
- 31:10Cloud infrastructure flexibility
- 32:26Fair work distribution
- 33:57Developer experience impact
- 36:29Summary of practices and data
- 37:57Selecting right metrics
- 41:21Q&A
related talks
33mMeasuring Developer Productivity: the good, the bad and the data
47mCan We Measure Developer Productivity?
31mDeveloper productivity is waste
31mHow Do You Measure Devel...
43mThe Past, Present and Future of Developer Productivity Theories and Metrics
27mDevelopers Expose What's Breaking Productivity in Their Companies
34mBuilding a Culture For Developer Productivity
18mFrom developer productivity to engineering impact
