Slow and boring: Secrets to building reliable software
summary
Argues that achieving real reliability requires organizational changes not just tech choices: commits to five nines for critical routes with a team under 20 engineers, runs teams at about 80% capacity (leave slack) to prevent burnout and reduce incidents, prefers kanban over packed scrum sprints, disperses reliability responsibilities instead of a separate SRE silo, hires for and rewards town planner skills, and uses simple metrics like days-since-last-failure to celebrate “nothing happening.”
AI-written summary · about
chapters (12)
- 0:00Introduction: why “slow and boring” matters
- 2:30The lasagna analogy: goals vs behavior
- 5:00Why reliability isn’t just about technology
- 7:30The danger of working at 100% capacity
- 10:30Creating slack for better engineering decisions
- 13:00Rewarding reliability (when nothing happens)
- 16:30Invisible teams vs “hero” culture
- 19:30Pioneer, settler, town planner model
- 22:30Hiring for reliability and team structure
- 25:00Why separate SRE/DevOps teams can fail
- 28:00Making reliability everyone’s responsibility
- 30:30Aligning reliability with business goals
related talks
29mThe Curious SRE: Cultivating a Mindset for System Resilience
27mThe Perverse Incentives of Reliability
43mBuild “boring” engineering orgs
20mDoing Things the Hard Way
05mKill the Project. Build a Team.
43mSweat the Small Stuff
28mAvoid overengineering & big ball of mud- 7 lessons for maintaining the balance
43mBetter Software Development Systems through Stress