Debugging product engineering organizations
summary
Claims a repeatable method — the double debugging loop — with four steps: surface the bug, diagnose (using value stream mapping and cross‑system maps), design and test fixes via hypothesis‑driven pilots and steel thread exercises, then deploy and measure with metrics like cycle time, WIP and uptime. Gives concrete failures (site outage taking days to root‑cause, product sprawl blocking speed) and executive pushback where a planned rollout scares leadership, illustrating when pilots succeed and when stakeholder permission is missing.
AI-written summary · about
chapters (10)
- 0:00From coding to changing systems
- 3:17Organizational bugs
- 7:29Double debugging loop
- 11:24Complex system bugs
- 14:32Root causes across subsystems
- 18:48Avoiding scapegoating
- 19:08Testing system fixes
- 23:05Fixes with measurable ROI
- 25:53No surprises in change
- 26:14Continuous improvement loop
related talks
26mDebugging Product Teams
11mBridging the gap between engineering and customer success
05mDebugging Like House - Software Differential Diagnosis
57mDebug your thinking
47mContinuous Deprovement will eat your product for breakfast
37mDebugging Engineering Velocity
10mDrive product gaps as an engineering leader
37mThe Bright Future of Debuggers: Challenges and Opportunities