Quick answer: Postmortems that name names produce conservative engineering. Postmortems that focus on system change produce learning. A simple template steers a team toward the second.
Most engineers will spend a week being subtly defensive after a bad postmortem. The right template doesn't punish; it isolates the system change that prevents recurrence.
Template: Timeline, Impact, Root, Fix
Four sections. Timeline = facts only. Impact = quantified. Root = system flaw, not human error. Fix = the change that makes recurrence impossible.
Use passive voice for actions
'The deploy was triggered' not 'Alice triggered the deploy'. The deploy was the system-level fact; who pressed the button is irrelevant to the postmortem.
Always ask 'what would have prevented this'
If the answer is 'the engineer should have been more careful', it's not a real prevention. If it's 'we should add a CI check that blocks PRs touching X without Y', that's a system fix.
Publish broadly
Postmortems are learning materials. Share within the org. Hiding them concentrates the lesson where the bug happened; sharing it inoculates the rest of the team.
“Blameless doesn't mean accountabilityless. It means the accountability is to the system, not the individual.”
Run a postmortem review monthly: of all the prevention items from past postmortems, how many shipped? If <50%, the postmortem process is performative.