The four parts
- What happened — facts. Timeline. What was planned vs. what actually shipped (or didn't).
- Why it happened — root causes. Not surface symptoms. Use 5-Whys or fishbone analysis.
- What we learned — generalizable lessons. Not specific to this team or this project.
- What changes — concrete process or system changes. With owners and dates.
Blameless
The single most important rule. Postmortems that name individuals teach future teams to hide problems. Postmortems that focus on systems and decisions teach future teams to surface problems. The site reliability engineering literature (Google's SRE book) is unequivocal on this.
↳ the political-cover trap
Make it readable
Most autopsies die in archived folders. The good ones get read by future teams considering similar work. Write the autopsy as if a stranger will read it in two years and decide something based on it — because that's what should happen.