Blameless Postmortem Checklist

“Blameless” gets thrown around as a vibe. It’s a checklist. Twelve prompts before you publish, six phrases to delete on sight, and the leadership rule that decides whether the room actually believes you.

Why “blameless” isn’t a vibe

Most teams say their postmortems are blameless. Most of those teams write postmortems that name a person, describe a mistake the person made, and end with action items that look suspiciously like “the person should be more careful”. That’s a blame postmortem with a polite tone.

The point of blameless isn’t kindness. It’s honesty. The moment a postmortem is read as “here’s who messed up”, the next incident’s responders will hide what they did and the postmortem will be useless. The checklist below is what makes the doc safe to read for the engineer named in it.

The 12 prompts

Run through these before publishing. If any answer is “no”, fix it before sending the doc:

1. Could a different engineer with the same context have made the same call?
2. Does the doc describe what someone did, not what they are? (“Engineer ran the rollback”, not “Engineer was hasty”.)
3. Are individuals named only when essential to the timeline? (Most aren’t.)
4. Is every “should have” backed by a system fix, not a personal one?
5. Does the action-items list have at least one item that fixes the system, not the person?
6. Have you removed the words “mistake”, “error”, “failed to”, and “careless”?
7. If the named engineer reads this in three years, will they still feel okay being mentioned?
8. Is there a section explicitly addressing what made the incident hard to detect?
9. Is there a section explicitly addressing what made the incident hard to recover from?
10. Are there at least two action items that nobody currently in the room is responsible for closing? (Forces broader system fixes.)
11. Does the doc say what was already done well? Most don’t. They should.
12. Has the named-on-the-bridge engineer read it and approved their portrayal?

Answer all 12 honestly and the doc will read blameless even if you didn’t consciously try.

Six phrases to delete

These six phrases sneak into postmortems and they all do the same thing: convert a system problem into a person problem. Delete them on sight:

• “X failed to verify…”, replace with “the system didn’t require verification”.
• “Should have known…”, replace with “the documentation didn’t cover” or “the alarm wasn’t there”.
• “Operator error”, never use. If a button caused damage when pressed, the button is the problem.
• “Could have caught…”, replace with “catching this would have required X, which we didn’t have”.
• “Lessons learned: be more careful”, not a lesson. Replace with the specific system change that removes the need for carefulness.
• “Process failure”, vague enough to mean nothing. Name the specific process step and what was missing from it.

The pattern: every phrase that deletes is the same shape, it locates the failure in a person rather than a system. Replacing it locates it in a system, which is the only thing you can actually fix.

The leadership-attendance rule

The single biggest predictor of whether a postmortem stays blameless is who’s in the room. Specifically: how many levels above the responders are present, and what authority they have to make people uncomfortable.

The rule we use: leadership above the team’s direct manager doesn’t attend the postmortem review. They get the published doc afterwards. The reason is simple: if a VP is in the room, the engineer who shipped the bad config is going to under-share. They’ll hedge, they’ll pre-defend, they’ll talk around what actually happened. The postmortem becomes a performance and stops being a learning tool.

This is uncomfortable for some leaders. The argument that wins: “If you want the engineering team to learn from this incident, the people who were on the bridge need to feel safe naming what they did. Your presence makes that harder, not impossible, but harder. Read the doc.” Most leaders accept this. The ones who don’t have a different problem on their hands.

The blameless room

A few rules for the room itself, beyond the doc:

• The facilitator is not the responder. Different person. Ideally not on the responder’s team.
• The first 10 minutes are timeline reconstruction only, no “why” questions yet.
• “Why” questions get reframed to “what made X likely”. The latter points at systems; the former points at people.
• The named engineer goes first when discussing what they did. They get to frame it; nobody else does.
• Action items are proposed by the room, not assigned by leadership. The team owns the fix list.

Aftermath

The blameless test isn’t in the doc; it’s in what happens to the named engineer afterwards. If the same engineer is on call next week, the team has done the work. If they’re quietly pulled off on-call for a month, or if their next perf review mentions the incident, the “blameless” label was a lie.

The follow-up question every team should ask three months later: “Did anything happen to the engineer named in the last postmortem that we wouldn’t have done if a different engineer had been on call?” If the answer is yes, the postmortem culture has work to do, regardless of how good the docs read.

The one-line summary, written into our on-call onboarding doc: “Blameless means the response to the incident is exactly the same regardless of who happened to be holding the pager.” Everything else is window dressing.