Blameless writing means you do not punish the person. It does not mean you hide what they did. Name the action plainly, then spend the rest of the document on what allowed that action to cause damage.
Most postmortems fail in the opposite direction. They go so soft that nobody can tell what happened.
"An incorrect configuration was applied to the production environment." Applied by whom, from where, with what on the screen at the time? All of that carries weight, and the passive voice threw it away in the name of kindness.
Being specific about actions is what makes a document blameless
A blameless postmortem is specific about actions and neutral about people. Those two things are compatible, and confusing them is the most common mistake in the genre.
Here is the difference. "The on-call engineer ran the migration against prod because the two terminal tabs looked identical and the prompt did not say which host it was" is blameless. It says exactly what happened, and the weight of the sentence lands on the tabs and the prompt.
"A migration was inadvertently executed in the wrong environment" is blurry instead. Nobody is protected by it, because everyone on the team already knows who ran it, and now the document cannot explain how it happened.
The reader you are writing for is the person who joins in eight months and hits the same wall. Blur protects nobody and teaches them nothing.
Write actions, then write conditions
The structure that works has two layers: what a person did, then what made that a reasonable thing to do at the time.
The second layer is where the real work lives. It is also the layer most drafts skip, which is why so many postmortems end with an action item that reads "be more careful".
The questions that reach it are simple, and they are all about the moment rather than the outcome.
- What was actually on the screen when the decision was made.
- What the alert said, in its own words.
- What the runbook told them to do at that step.
- What the previous few incidents had trained them to expect.
- How long they had been awake.
If a competent person, working from those answers, would have done the same thing, you have found your actual finding. And note that the last question is a fact about the system rather than an excuse for the human: "the on-call engineer was forty minutes into a 3 AM page" belongs in the document.
Words that quietly assign blame
Some vocabulary carries a verdict whether you meant it or not.
- Failed to, as in "the operator failed to verify". You are describing a missing step, so describe the step.
- Obviously, which says the answer was right there and somebody walked past it.
- Should have, which grades a decision using information the person did not have yet.
- Human error as a root cause, which records where the investigation stopped, not where it should have ended.
- Inadvertently and accidentally, which sound generous and mostly signal that you are uncomfortable.
Replace them with what was actually in front of the person. Instead of "failed to check the host", write "the check is step 4 of the runbook, which sits below the fold on a laptop screen". Now there is something to fix.
Hindsight is the enemy of a useful document
Everything looks obvious once you know the ending, and a postmortem written from that vantage point teaches the wrong lesson.
The way out is to write the timeline in the order the responders learned things, not in the order things were true. Include the wrong hypotheses. Include the twenty minutes spent on the theory that turned out to be unrelated.
Those dead ends are the most valuable part of the whole document. They show what the evidence looked like from inside, and they are the reason the next person will not spend the same twenty minutes.
I would go further: a postmortem with no wrong turns in it is probably a lie. Real incidents are confusing while they are happening. A clean narrative usually means somebody tidied.
Cap the actions, and record the ones you rejected
A postmortem with fourteen action items produces roughly the same outcome as one with zero, so cap the list at about three and write down what you decided not to do.
The cap is about memory rather than discipline. Nobody holds fourteen commitments once the urgency fades, and the ones that survive are chosen by accident rather than by importance.
The rejected fixes are the part unique to this document. "We considered a confirmation prompt and decided a prompt on every deploy costs more than this failure mode" is a finding, and it is the finding that stops somebody proposing the same thing next quarter and getting a different answer.
Say who owns each one and by when, in the item itself. Then let the ownership be somebody's actual job rather than a line in a document nobody reopens.
Write it the way you would explain it over coffee
Use the voice you would use with a colleague you respect, the day after, once everyone had slept.
A legal filing is the wrong register and so is an apology. Corporate flatness reads as concealment to anyone outside the team, and it reads as boredom to everyone inside it.
You are allowed to write "this one hurt" or "we got lucky with the timing here". Those sentences carry information about severity that no chart does.
The rule I hold myself to when writing these for Unvent is that the document has to survive being read by me in a worse mood. My first drafts are always a little pleased with how the problem was found. The second draft takes that out, and what is left is duller, longer in the middle, and the only version anybody could use.
Publish it wider than feels comfortable
Share the postmortem with people who were not involved, because that is the only way it becomes institutional memory instead of a private note.
Wide circulation also disciplines the writing. A document a stranger will read cannot lean on shorthand, and it cannot pretend the cause was mysterious.
The thing to watch for is whether people volunteer to write them. If your postmortems are genuinely blameless, engineers start raising their hand for the one they were at the center of, because it is the fastest route to getting the system fixed. If nobody volunteers, the document says blameless and the room says something else.
Direct about the facts, neutral about the people
Unvent rewrites what you are typing, in place, in the tone you pick. Your incident write-up can name exactly what happened and still read as calm rather than accusing.
Add Unvent to Chrome