How to Run a Postmortem Without Pointing Fingers
Something broke. Maybe it was a bad deploy that took down part of the product for an hour. Maybe it was a feature that shipped and quietly caused a spike in support tickets for two weeks before anyone connected the dots. Either way, there’s now a meeting on the calendar called “postmortem,” and everyone walking in already has a slightly different idea of what it’s for. Learning to run a postmortem without pointing fingers is mostly about making sure it stays the first kind of meeting, a chance to figure out what went wrong so it doesn’t happen again, rather than the second kind, where people are quietly trying to find out if they’re in trouble.
How the meeting is run determines which one it actually becomes. A common way this goes wrong: the facilitator opens with something like “let’s walk through what happened, starting with the deploy” — technically neutral wording, delivered while looking straight at the engineer who pushed the change. That combination reads instantly, and the room adjusts accordingly. The engineer gives the shortest possible version of events and volunteers nothing extra, and the fuller picture doesn’t surface until a one-on-one conversation days later, by which point the meeting has already done its damage.
Why blame derails postmortems before they start
The instinct to look for “who” rather than “what” is pretty natural. Something went wrong, someone presumably did the thing that caused it, and finding that person feels like progress. The problem is that this framing, even when nobody says it out loud, changes how people behave in the room. It’s the same dynamic that shows up in giving feedback without demoralizing your team, the moment someone feels evaluated rather than heard, the useful information dries up.
If there’s any sense that this meeting is about assigning blame, people get cautious. They volunteer less. They frame their part of the story in ways that minimize their own role, sometimes without even realizing they’re doing it. And the person who’s most likely to have useful information, usually whoever was closest to the decision or the code that caused the issue, is also the person with the most reason to be guarded.
The result is a postmortem that produces a tidy-looking narrative, but one that’s been quietly shaped by everyone’s instinct toward self-protection. You get a story, but maybe not the most accurate one, and the action items that come out of it tend to be shallow as a result, often landing on something like “be more careful” or “add another review step,” which sound like fixes but rarely change anything.
There’s also a second-order effect that’s easy to miss: once a team has been through one postmortem that felt like a blame exercise, the next incident is less likely to get reported quickly, or at all, if it’s small enough to plausibly go unnoticed. Nobody wants to be the one who raises their hand for the second time. This runs directly against what a postmortem process is supposed to encourage, early, voluntary disclosure of problems, and it tends to happen quietly enough that leadership often doesn’t realize it’s happening until a small issue has had time to become a much bigger one.
Setting the tone: ground rules to run a postmortem without pointing fingers
The tone gets set in the first two minutes, and mostly by whoever’s running the meeting. Saying explicitly, at the start, that this isn’t about who’s at fault, that the assumption is everyone involved was doing reasonable things with the information they had at the time, does more than it might seem like it should. It permits people to be honest about their part in what happened, which is exactly the information the postmortem needs.
This only works if it’s actually true, though. If the postmortem is blameless in the room but someone gets quietly dinged in a performance review later for the same incident, that gets around, and the next postmortem will be a lot more guarded, because people will have learned what “blameless” actually means in practice at this company. Google’s SRE book describes this directly: a blameless culture only holds if the org actually treats incidents as an opportunity to learn rather than a chance to assign fault, consistently, not just in the room where the postmortem happens.
It also helps to separate the incident from the people in the room as explicitly as possible. Talking about “what the system allowed to happen” rather than “what someone did wrong” is a small language shift, but it reframes the whole conversation. Almost every incident, when you look closely, involves a system that made a mistake easy to make: a confusing interface, a missing safeguard, unclear documentation, a process with no second check. Focusing there tends to be both more accurate and more useful than focusing on the individual decision someone made in the moment.
Getting to the root cause without naming names
A genuinely useful postmortem usually involves asking “why” more than once, the same discipline that makes a good sprint retrospective actually change something instead of producing the same three action items every time. The first answer to “why did this happen” is often something like “someone deployed a change that had a bug in it.” That’s true, but it’s also not very actionable. “Don’t deploy bugs” isn’t a real strategy.
Asking why again: why did that bug make it to production? Maybe testing didn’t cover that scenario. Why didn’t it? Maybe that scenario wasn’t considered likely, or wasn’t easy to test in the existing setup. Why not? Maybe the testing environment doesn’t closely match production for that kind of case.
By the third or fourth “why,” the conversation is usually somewhere more useful, not “a person made a mistake” but “the testing environment doesn’t reflect a class of real-world conditions, and that’s been true for a while; this is just the first time it caused a visible problem.” That’s something a team can actually act on, and notably, it’s not really about any person at all.
It helps to build a timeline of what happened, as factually as possible, before jumping into analysis, what was deployed, when, what alerts (if any) fired, when the issue was noticed, by whom, what happened next. Having this laid out, agreed on by everyone in the room, gives the group a shared factual basis before the “why” questions start, which helps keep the discussion grounded rather than turning into competing narratives about what happened.
One thing worth watching for during the “why” chain: it’s tempting to stop as soon as the discussion reaches an answer that feels satisfying, even if it isn’t the most useful stopping point. “The engineer didn’t notice the warning in the logs” can feel like a complete answer, because it identifies a specific moment where something could have gone differently. But the more useful question is often “why wasn’t that warning more visible” or “why did the system allow that condition to occur without a more forceful signal.” The first framing ends with a person. The second one ends at something the team can actually change, which is usually the better place to stop, even if it takes an extra “why” or two to get there.
Turning findings into action items that stick
The output of a postmortem is only as good as what happens after the meeting ends, and this is where a lot of postmortems quietly fail, not in the meeting itself, but in the weeks after, when the action items either don’t get done or turn out to be too vague to act on in the first place.
Vague action items are the biggest culprit. “Improve testing” or “communicate better” sound like progress in the meeting, but they’re not specific enough for anyone to actually do anything with, and they’re impossible to verify later. There’s no way to know if “testing” got “improved” enough.
Specific, scoped action items work better, even if there are fewer of them. “Add a test case covering [specific scenario] to the CI pipeline” or “create a runbook for [specific situation] so the on-call person has a clear process next time,” these have a clear definition of done, a natural owner, and can actually be checked off. Atlassian’s incident postmortem guidance makes the same point: an action item that can’t be verified as done is really just a wish.
It’s also worth being honest about the fact that not every issue is worth fixing immediately or fully. Sometimes the root cause points to something that would take significant effort to address, and the realistic outcome is “the team is accepting this risk for now, here’s why, and here’s what would change that calculus.” That’s a legitimate outcome of a postmortem, not every finding needs to turn into a project.
This kind of honest risk-acceptance is also where a blameless culture pays off in a less obvious way. If a team feels safe saying “this would take a quarter to fix properly, and it’s not worth that right now,” that’s useful information for leadership, it surfaces a real tradeoff that’s being made, even if implicitly, and gives someone above the team a chance to weigh in if they disagree with the call. This kind of openness is closely tied to the same trust described in using OKRs without losing team trust, people only surface hard tradeoffs honestly when they believe honesty won’t be held against them later. A team that’s nervous about appearing to “not fix things” is more likely to either overcommit to fixes it won’t actually get to, or quietly let the issue drop without anyone deciding that on purpose, neither of which is as useful as a clearly stated, deliberate tradeoff.
What it looks like to run a postmortem without pointing fingers over time
The real signal that a postmortem process is working isn’t any single meeting, it’s what happens over months. Do similar issues stop recurring? Do people bring up near-misses voluntarily, before they become real incidents, because they’ve seen that doing so doesn’t lead to blame? Do postmortems get a little less dramatic over time, because the team has gotten better at catching things earlier?
One thing that tends to happen in teams that get this right: postmortems stop being reserved only for major incidents. Smaller issues, things that almost became a problem, or minor bugs that revealed something about how the system or process works, get the same lightweight treatment. This normalizes the process, so that when something bigger does happen, the postmortem isn’t a rare, high-stakes event that everyone’s nervous about. It becomes what happens after something breaks, the same as it always does, the same lightweight habit worth building into a first product launch from day one, rather than treating a structured close as optional.
The role of whoever’s running the meeting
It’s worth saying directly: a lot of whether a postmortem stays blameless comes down to the facilitator, often the PM, actively managing the conversation in the moment, not just setting the tone at the start and then stepping back.
If someone in the room does slip into blame-adjacent language, even something as subtle as “well, someone should have caught that,” it’s worth gently redirecting in the moment, rather than letting it sit unaddressed. Something as simple as “let’s come back to what would have caught that, rather than who” keeps the conversation on track without making a big deal of the comment itself. Left unaddressed, even one moment like this can shift the tone for the rest of the meeting, because everyone in the room is watching for exactly this kind of signal about whether “blameless” is actually being upheld.
It also helps for the facilitator to model the thing they’re asking of others, being willing to say “this risk should have been flagged earlier, and it wasn’t” if that’s true, even if the facilitator is also the PM whose job includes catching exactly this kind of thing. A facilitator naming their own miss out loud is one of the more reliable ways to get a nervous room to relax. Nothing sets a tone faster than seeing the person running the meeting hold themselves to the same standard they’re asking from everyone else. Etsy’s engineering team has written about this pattern as part of the postmortem culture they’ve documented over the years: the facilitator’s own candor sets the ceiling for everyone else’s.
Blameless Postmortem Template
| Section | What Goes Here |
|---|---|
| What Happened | Brief, factual summary of the incident and its impact |
| Timeline | Chronological sequence of events — deploys, alerts, detection, response, resolution. Times and actions, not judgments |
| Contributing Factors | What conditions made this possible or more likely: not who did what, but what about the system, process, or environment contributed |
| What Went Well | What worked during detection or response — worth noting, not just what went wrong |
| Action Items + Owners | Specific, scoped, verifiable changes. Each has a clear owner and, where relevant, a decision to accept a risk rather than address it explicitly |
Learning to run a postmortem without pointing fingers, at bottom, isn’t about pretending nothing went wrong or being soft on accountability. It’s the opposite, in a way, it’s the version of the process that actually gets to what happened, because nobody’s spending energy protecting themselves. That’s not just more pleasant. It’s more accurate, and it’s the only version that reliably leads to things actually getting better.
References
- Google SRE — the SRE book’s chapter on blameless postmortem culture
- Atlassian — guidance on running incident postmortems
- Etsy Code as Craft — writing on postmortem culture and practice
