No Time to Do It All! Approaching Overload on DevOps Teams
summary
Models a single service with a 4-engineer model writing 150,000 LOC, with bugs fixed in 1 hour if the author remains or 10 hours if not, showing backlog rising to ~15,000 hours/year; capping fixes at 1,500 hours causes monotonic knowledge decay. Explains pair programming and migrations as interventions (pairing preserves context after attrition; rewriting half the code cuts annual fix hours from ~15k to ~8k). Covers frameworks: Overload in Joint Cognitive Systems, WIP spirals and the utilization trap, plus practical limits like WIP caps.
AI-written summary · about
chapters (16)
- 0:00Introduction
- 1:21Understanding overload
- 3:34Alex's truths
- 6:22Overload vs pain points
- 7:24Four responses to overload
- 10:39Simulating team overload
- 13:53Knowledge decay impact
- 15:41Retention and robustness against employee turnover
- 16:22Pair programming benefits
- 17:50Proactive migrations
- 19:13Building migration muscles
- 21:01You touch it you own it
- 24:47Flow theory capacity
- 27:15Batch size impact
- 29:41WIP limits whip
- 32:14Long-term overload solutions
related talks
39mThe systems thinking view on developer productivity and experience
33mTools over Processes over People... Or Not?
39mImplementing Programmer Anarchy
46mLet Them Eat Code
05mThe perfect match: How Extreme Programming enables Team Topologies concepts
53mHatching software development ecosystems (the gordian knot)
58mDevOps @ Scale — Greek Tragedy in Three Acts
29mDevOps Transformation at Scale