RESEARCH_TIMELINE
The Science of Engineering Incidents and Identity: Why It's Rarely the Villain's Fault
"Who broke prod?" feels like the right question after an outage. Systems research gives a less satisfying but far more useful answer: complex systems fail through the alignment of many small conditions, not through one reckless actor (Reason 1990; Google SRE 2016). Meanwhile the people most responsible for keeping those systems alive — the ones doing infrastructure work, on-call rotations, and glue work — are systematically under-credited (Champion et al. 2024). And now a new identity threat layers on top: AI tools that promise to replace engineers are trusted by a shrinking minority of developers (Stack Overflow 2025). The old script — 'someone here is the villain' — is almost always the wrong read.
How the science changed · 1983–2024
- 1983
Arlie Hochschild's The Managed Heart coins the concept of emotional labor — work that requires managing one's feelings as part of the job but goes unmeasured in any formal accounting. The concept later anchors research on invisible glue work in software teams. ↗
- 1990
James Reason publishes Human Error, introducing the Swiss cheese model of accident causation: failures happen when holes in multiple defensive layers align, not because one person made one mistake. The model becomes foundational to aviation, medicine, and later software reliability. ↗
- 2006
Sidney Dekker's The Field Guide to Understanding Human Error reframes 'human error' as a symptom, not a cause — the engineer who clicked the wrong button did so inside a system that allowed or encouraged that action. Blame, Dekker argues, stops investigations at the wrong layer. ↗
- 2012
John Allspaw and Jesse Robbins popularize blameless postmortems at Etsy, arguing that engineers who fear punishment hide information — and hidden information kills reliability. Their approach later influences Google's Site Reliability Engineering practice. ↗
- 2016
Google publishes its SRE Book, dedicating a full chapter to postmortem culture. The chapter codifies blamelessness as an organizational policy: 'the primary goals of writing a postmortem are to ensure the incident is documented, all contributing root causes are understood, and effective preventive actions are put in place.' ↗
- 2018
Forsgren, Humble, and Kim publish Accelerate, correlating organizational practices with software delivery performance across thousands of teams. Their data shows that high-performing teams are distinguished not by blame-free heroes but by psychological safety, fast feedback loops, and distributed ownership of reliability. ↗
- 2024
Champion et al. publish a large-scale empirical study of invisible labor in open source software ecosystems: infrastructure maintenance, documentation, code review, and community management are systematically under-recognized compared to feature commits — and the gap disadvantages engineers who specialize in reliability over novelty. ↗