Blame in a postmortem usually shows up as a named person in the cause, loaded adjectives, or "should have" statements. Rewrite each to describe what the person knew, what the system allowed, and what will change. The goal is accurate facts that keep people willing to speak up.
Why editing for blame matters
Google's SRE book says a postmortem can only be blameless if it identifies contributing causes without indicting any person or team, and that it should assume everyone had good intentions and did the right thing with the information they had. Its reasoning is practical: when blame prevails, issues get swept under the rug, and risk grows.
The Workbook adds that naming individuals leads people to become risk averse and possibly hide facts that matter for prevention.
Editing for blame is not the same as removing accountability. See blameless does not mean no accountability.
Four patterns to catch
| Pattern | Before | After |
|---|---|---|
| Named cause | "Dana pushed the key to the repo." | "A deploy key was committed to a repository. Nothing in the pipeline checked for it." |
| Loaded adjective | "The careless change bypassed review." | "The change reached production without review because the branch rule allowed admin merges." |
| Hindsight verdict | "Ops should have noticed the alert." | "The alert fired at 02:10 and was routed to a channel with no on-call. We will route it to a pager." |
| Training as fix | "Remind staff not to click links." | "Add a control that does not depend on every person being perfect." |
The last row reflects a point in the Workbook: changing human behaviour is generally less reliable than changing automated systems and processes. Its sample bad postmortem lists an action to train people not to run unsafe commands, and criticises it.
A five minute editing pass
- Search the draft for first names and handles. Replace them with roles.
- Search for "should have", "failed to", "careless", "obviously", "ridiculous" and exclamation marks.
- For every cause sentence, ask: what did this person know at the time, and what made the wrong path easy?
- Check each action item. If it reads "tell people to", look for a system change instead.
- Read it aloud as if you were the person involved. Would they say it is fair?
The Workbook also flags animated language: a postmortem should be a factual artifact that considers multiple perspectives and is respectful. Use verifiable data to justify the severity of a statement, not adjectives.
What not to over-correct
Blameless does not mean vague. If a control was bypassed, say that it was bypassed. If a process was not followed, say what made it hard to follow. Pushing everything into passive voice hides who needs to be consulted. Name roles and decisions, then explain the context around them. The point is to explain, not to protect.
Also check the "human error" label. If the draft ends the analysis at human error, keep asking why. Our post on human error is not a root cause goes through it.
How Safeguard fits
A system change that makes the right path the default is often a gate in the pipeline. Safeguard's policies, gates and guardrails can enforce dependency and build rules, and a free scan is available at https://gold.safeguard.sh/scan.
Quick check
Can a postmortem name the engineer who made the change?
Describe the action by role, such as "the on-call engineer". The review should explain the context, not point at a person.
What if leadership uses blame in the meeting?
The Workbook suggests redirecting by asking generically what warning signs existed and why they might have been dismissed.
Sources
Last reviewed: 19 October 2026.
