How to Run a Post-Mortem That People Actually Read

The Post-Mortem Nobody Reads

Most post-mortems end up in a shared drive, opened once by the person who wrote them and never again. The team spent an hour in a room. Someone typed up three pages. The document landed in a folder called "Incidents" and quietly gathered dust.

This is not a documentation problem. It is a design problem. The post-mortem format most teams use optimizes for completeness when it should optimize for change.

Why the Standard Format Fails

The typical post-mortem template asks for a timeline, a root cause, a list of action items, and sometimes a severity rating. This produces a thorough historical record. It also produces something nobody wants to read.

Three reasons:

Length kills distribution. A 2,000-word document with a minute-by-minute timeline is useful to the person who lived through the incident. For everyone else, it is homework. People skim it, absorb nothing, and move on.

Root cause is a trap. Complex systems rarely fail for one reason. Labeling a single root cause gives the team a neat story and a false sense of closure. The real lesson — the systemic condition that allowed the failure — gets buried under the narrative.

Action items decay. A list of twelve action items looks productive on Friday. By the following Thursday, eight of them have been deprioritized. The post-mortem becomes a monument to good intentions.

A Format That Earns Attention

Replace the standard template with three sections: Context, Surprise, and One Change.

Context (two to three sentences)

State what happened and who it affected. No timeline. No minute-by-minute replay. Give a reader enough to understand the stakes without asking them to reconstruct the incident in their head.

Think of it as the sentence you would say to a colleague in the hallway: "The billing job ran twice on Tuesday, and 400 customers got duplicate charges."

Surprise (one to two paragraphs)

This is the section that matters. Answer one question: what did this incident reveal that we did not already know?

Every incident contains a surprise. Sometimes it is technical — a failure mode nobody anticipated. Sometimes it is organizational — the alert fired but the on-call engineer did not have permission to act on it. Sometimes it is a gap between what the team believed and what was true.

Name the surprise clearly. This is the part that transfers knowledge. A reader who never touched the incident can still absorb the surprise and carry it into their own decisions.

If you cannot articulate a surprise, the post-mortem is not ready to publish. Go back and dig.

One Change (one paragraph)

Propose exactly one change. Not five. Not twelve. One.

This forces a hard conversation. If the team can only pick one thing to do differently, they have to identify the highest-value intervention. That conversation is more useful than any action-item spreadsheet.

One change is also easy to track. Next month, either you made it or you didn't. No ambiguity, no half-credit.

Who Writes It and When

The person closest to the incident writes the draft. Not a manager. Not someone assembling secondhand accounts. The person who was paged, who noticed the anomaly, or who made the call that contained the damage.

Write it within 48 hours. Memory degrades fast, and so does emotional honesty. The discomfort of an incident is useful — it makes people precise. A week later, the rough edges have been sanded down and the document reads like a press release instead of a lesson.

Make It Visible or Don't Bother

A post-mortem locked in a subfolder teaches nobody. Publish it where the team already looks — the channel they check daily, the weekly digest, the standup notes. Put the Surprise in the subject line so people understand the value before they click.

Some teams resist this because post-mortems feel vulnerable. They describe mistakes. They admit gaps. Publishing them widely requires a culture where admitting "we didn't know this" is treated as professional, not embarrassing. That culture does not appear on its own. Leaders build it by publishing their own post-mortems first.

The Real Test

A post-mortem earns its cost only when it changes the next decision. Not the last one — that decision is already made. The document exists to reach someone who has not yet faced this situation and give them one sentence they will remember when they do.

If your post-mortems are thorough but unread, they are failing that test. Make them short. Make the surprise obvious. Commit to one change. Put it where people will actually see it.

The goal is not a perfect record of what went wrong. The goal is a team that gets slightly better each time something breaks.