An incident review that people dread produces worse incident reviews, because the people who know the most start saying the least.
The rule that changed the tone
No sentence in a postmortem is allowed to name a person as the cause of anything. Every sentence is required to name a decision, an assumption, or a gap in the system that allowed the incident to happen — including decisions that were reasonable at the time they were made.
What the template actually asks
- Timeline — what happened, in order, with timestamps, no interpretation yet.
- What went right — genuinely, not as a courtesy. Monitoring that caught it fast, a rollback that worked cleanly, a team that communicated well under pressure. These get named specifically so they are reinforced, not just assumed.
- The decision that made sense at the time — the assumption that seemed reasonable when it was made and turned out not to hold. This is the section that used to get skipped, and it is the most useful one.
- What would have caught this sooner, as a system property, not a person's vigilance.
Why "the decision that made sense at the time" matters most
Blaming an outcome is easy and teaches nothing, because the person who made the call already knows it went wrong. The useful question is why it looked correct at the time, because that is the gap — in information, in tooling, in process — that will produce the next incident if it is not closed.
If your postmortem's conclusion is "be more careful", you have not found the cause yet.
What we do with the output
Every postmortem produces at least one concrete action with an owner and a date, tracked the same way a client deliverable is tracked. A postmortem that ends in a discussion and no action item did not, in our experience, change anything the next time.
The effect on how people report incidents
Once the format stopped assigning blame, the time between an incident happening and someone flagging it dropped noticeably. People report problems faster when reporting one does not feel like a confession.