Postmortems are stories, not checklists.
The strongest postmortems I've read all share a structure that has nothing to do with the templates we keep handing each other. Here's what they share — and a worked example.
The best postmortem I have ever read was a single page, written in plain prose, with a chronology that read like a short story. It did everything our templates are supposed to do and none of the things they encourage.
What templates do wrong
Templates promise consistency and deliver compliance. You end up with sections that are filled because the section exists, not because there’s anything to say. “Detection time: 4m.” “Resolution time: 21m.” “Root cause: a configuration error.” Three lines of metadata, zero understanding.
What good ones share
Three things, in my experience:
- A narrator. Someone tells the story in first person. The pronoun matters.
- A turn. The moment the incident changes shape, and what the team noticed about that change.
- A lesson, not a list. One thing the team learned, said in plain language, not a bulleted action-items grid.
If you can name the narrator, the turn, and the lesson, the postmortem is good. If you can’t, it’s a form.
A worked example
You can write the chronology any way you like. But if every event line on the timeline is “X happened at HH:MM,” you’ve written a log, not a story. A story has cause and effect. Logs don’t.
The next time you write one, try this: delete every section header and write three paragraphs. If they don’t fit, the template was the problem.