Learning from incidents: how things went right
summary
Research shows focusing on human error hides design faults: hundreds of B-17 gear-collapse accidents trace to identical switches and stop after simple shape-coding, not blame. Four investigative traps are named (attribution, counterfactuals, normative language, mechanistic thinking) and four practices are recommended: run a 90-minute facilitated post-incident review, pre-interview responders, ask “how” (how did recovery happen, where did we get lucky), and hold a separate repair-prioritisation meeting with managers afterward.
AI-written summary · about
chapters (25)
- 0:00Introduction
- 2:02B17 Flying Fortress
- 4:03Structure
- 5:24Complex systems
- 7:30Automated systems
- 9:12Resilience engineering
- 13:17Human error is a symptom
- 14:04Counterfactual reasoning
- 14:19What is counterfactual reasoning
- 14:33Trap 2 Counterfactual reasoning
- 15:35Trap 3 Normative language
- 16:58What is mechanistic reasoning
- 19:12Summary
- 19:40Postincident review meeting
- 19:56Facilitated postincident review
- 22:23Helpful practice ask better questions
- 23:13How work normally happens
- 23:55Why things go wrong
- 24:15Recovery
- 26:01Repair items
- 27:24Three most important aspects
- 27:35We will always have incidents
- 28:01Human error 2
- 28:20Postincident review
- 28:40Outro
related talks
40mBuilding Resilience: How to Learn More from Incidents
30mPilot your Project: Avoiding Anti-Patterns While Handling Incidents and Planning
37mIncidents are a new normal
05mLearning From Failure: How We Learned a Better Way
03mRecap
31mThe blameless post mortem: how embracing failure makes us better
30mHow Did Things Go Right? Learning More from Incidents
15mPragmatic Incident Response: Lessons Learned from Failures