Measure for change
summary
Claims that metrics must tie metrics to decisions, involve teams, and always follow up; measurement alone does not improve outcomes. Examples and numbers: fizer achieves 22% more devs deploying <1 hour, ~33% resolving incidents <1 hour and a 6.6% lift in perceived quality; gfk saves ~400 hours/week after adding qualitative measures; versell sustains >95% survey participation and 80% of teams take action. Tools and tactics: combine survey sentiment with CI/build success, capture in‑moment feedback (Backstage, PR hooks, GitHub Copilot), then close the loop.
AI-written summary · about
chapters (11)
- 0:00Measuring developer productivity
- 2:31Why measurement alone doesn’t improve productivity
- 4:40Fizer’s team-involved metrics
- 6:46Limits of quantitative metrics
- 9:57Qualitative data completes the picture
- 11:40Teams know problems best
- 13:47Qualitative data challenges
- 16:36Boosting survey participation
- 18:22Real-time feedback for improvement
- 20:29Focus on knowledge work
- 21:34Teams drive real change
related talks
31mMetrics Mania. Obsession with Measurement can Harm our Teams
47mWhat's Measured Improves: Metrics that Matter
20mHow to Communicate Metrics to Build Engagement
41mRethinking Measurement for High-Performing Teams
42mMeasuring Agile success
47mCan We Measure Developer Productivity?
31mHow Do You Measure Devel...
06mDelivery Metrics: the good, the bad, and the totally ridiculous