1. Blameless is a practice, not a policy
Every incident-response doc on earth says "we are blameless." Most incident cultures are anything but. There is a gap between the policy on the page and the language in the room, and engineers can hear it immediately. The policy is the easy part. The practice is the work.
Blameless doesn't mean nobody made a mistake. It means the interesting question is not "who screwed up" but "what did our system allow?" A production incident where a single engineer's action broke things is, almost always, a system that made that action too easy and its consequences too invisible.
2. Watch the pronouns
The language in the postmortem tells you the culture more than the template does. Compare:
Blame: "Alex deployed the change without running the migration first."
Blameless: "The deploy pipeline allowed a schema-changing deploy to proceed without a migration check. The engineer executing the deploy had no signal that a migration was required."
Same facts. Different story. The second version routes attention to the fix (guardrails in the pipeline). The first routes attention to the person, and quietly teaches everyone in the room to hide near-misses in future.
Every time a name appears in a root-cause section, ask whether it can be replaced with a system-level noun. Nine times out of ten it can, and the postmortem is stronger for it.
3. Get the severity ladder right first
Culture around incidents starts upstream of the incident itself. If your severity ladder is unclear, every incident escalates or none do. Both failure modes are expensive.
A workable four-tier model:
- SEV-1. Customer-visible outage of a core flow, or data at risk. All hands, war room, exec notified inside the hour.
- SEV-2. Significant degradation or partial outage. On-call and team lead engaged. Update stakeholders.
- SEV-3. Minor degradation, workaround exists. Fix in-hours.
- SEV-4. No customer impact, latent risk. Ticket it.
Each tier has a defined response, escalation path, and — this matters — a defined limit on what it is allowed to interrupt. SEV-3s do not wake people up. SEV-1s interrupt anything. When the ladder is clear, people escalate correctly. When it isn't, they escalate defensively and burn out.
4. The postmortem shape
Every SEV-1 and SEV-2 gets a written postmortem within a week. The shape:
- What happened. Timeline in UTC, with the customer impact.
- What we noticed and when. Detection lag is often the real problem.
- What we did. Mitigations, decisions made under pressure, dead ends.
- Root cause(s). Contributing factors, not a single villain.
- What went well. Not filler — a place to name and reinforce the behaviours you want repeated.
- Action items. Owner, due date, priority. Filed as tickets, tracked on a board.
The tone throughout is curious, not defensive. The author's job is to make the system stronger, not to make the team look good.
5. Follow-through is where culture actually lives
A postmortem without follow-through is theatre. Everyone knows it. The action items get filed, marked "must-do," and then quietly rot for a quarter until the same incident happens again — and the retro is more cynical the second time.
Treat postmortem action items like customer-facing tickets. Owner, due date, board. Reviewed in the same forum as feature work, not in a separate "reliability graveyard" that nobody reads. If a P0 action item isn't done in the promised window, that itself is a topic for the next operating review.
If your team's action items from three incidents ago are still open, do not run a fourth postmortem the same way. Fix the follow-through system first. Otherwise you are training the team that writing postmortems is optional.
6. Reward the writer
Culture follows what leaders publicly reward. When someone writes a great postmortem — clear, honest, action-oriented — say so, in the channel, by name. When someone escalates a near-miss that could have been swept under a rug, thank them, publicly. The people you praise are the people the team learns to become.
The opposite is true too. If the only visible signal after a bad incident is quiet disappointment and a slower promotion, the message the team hears is: don't get caught. That is the seed of a blame culture, no matter what your policy says.
7. Final takeaway
Incidents are, weirdly, one of the highest-leverage teaching moments a leader has. They compress a lot of decisions and a lot of humanity into a short window. Handled well, they compound into a stronger system and a team that trusts each other more. Handled badly, they teach everyone the exact opposite lesson — and the next incident will be harder, not easier.