You've read the Google SRE book. Your team knows the theory. Postmortems are blameless, psychologically safe, and thoroughly documented. And six months after your last major incident, the same failure pattern showed up again — different service, same root cause, new person holding the bag.
The uncomfortable truth: blamelessness was never the finish line. It was the entry fee.
Most teams learned this lesson and stopped there. They eliminated blame, got honest accounts of what happened, and then filed those accounts in a folder nobody opens. As one practitioner put it, "a postmortem without a mechanism is a diary entry." The document was thorough. It just had no mechanism attached to it.
Blame Is Gone. Theater Replaced It.
The shift away from blame culture was real and necessary. Etsy's foundational writing on blameless postmortems made the argument that you cannot get an honest account of what happened from people who expect consequences for giving it — and that argument won. Most engineering teams at mid-stage startups have internalized it.
But there's a second failure mode that's subtler and far more common in teams that have already read that chapter. The postmortem is scrupulously blameless, well written, thoroughly reviewed, and produces nothing. Everyone leaves the meeting agreeing it was valuable. Nothing changes. The same incident recurs five months later.
What replaced blame wasn't accountability — it was ritual. Someone opens a Google Doc with a template copied from a blog post three years ago. They fill in the timeline because that part's easy. They list action items because the template has a section for it. The doc gets shared in Slack, two people add comments, and then it goes into a folder no one will ever open again. Six months later, the same incident happens.
The postmortem isn't failing because people don't care. It's failing because we treat it like a compliance exercise instead of an engineering practice. The process was designed to produce a document, not understanding.
The Timeline Is Where You're Hiding the Real Work
Most postmortem timelines smuggle in judgment while appearing neutral. Consider the difference between these two entries:
"14:12 — Engineer restarted the primary database, causing 8 minutes of write failures."
versus
"14:12 — Dashboard showed connection pool at 100% and query latency climbing. Runbook step 3 says restart the primary. Engineer restarted the primary. Writes failed for 8 minutes."
The first version has a person causing a failure. The second version has a runbook giving dangerous advice under a condition its author didn't anticipate. Same event, same person, completely different outcome for the team.
This is why a postmortem that ends with a person's name has already failed. One practitioner watched a postmortem collapse into "Marek pushed the change without checking" — everyone nodded, the meeting ended early, and six weeks later someone else, following the exact same deploy process, took the same system down the same way. Marek had left the company by then. The person is the trigger. The missing guardrail, the silent failure mode, the deploy step with no confirmation — that is the cause.
The timeline discipline that actually works: write what the person doing it could see at that moment, not what you know in retrospect. A postmortem without diagnostic false leads, dead ends, and decision points merely records that things happened — it does not preserve the reasoning that would let someone else walk the same path. That constraint forces you to surface the information gaps, the misleading runbook steps, the alerts routing to channels nobody watches on weekends — the system conditions that made the failure available to any human who walked into that situation.
The level at which an engineer tells the incident story matters too. The same outage, with the same technical root cause, reads completely differently depending on where the engineer decides the problem ends — whether they stop at the fix, or keep pulling the thread back to the system conditions that made the failure possible. A postmortem that stops at "we fixed the connection pool" is a different document than one that asks why an external HTTP call was ever happening inside an open database transaction in the first place.
Action Items Without Owners Are Wishes
The other place postmortems die is the action items section. Teams generate them, assign them to "the team" or to a vague future sprint, and then wonder why nothing changes.
The tell that a postmortem process has stopped working: someone opens an incident channel and within ten minutes someone says "didn't we have this exact thing in March?" Somebody digs out the old document. It has a root cause section, a timeline, and four action items — none of which were ever done.
The fix isn't more process around action items. It's fewer action items with harder ownership. Three action items with named owners and a follow-up date in the next sprint review will outperform twelve items assigned to "eng team" every time. The postmortem meeting isn't where the learning happens — it's where you negotiate what you're actually going to change. Everything else is documentation.
One more thing worth naming: stop looking for the root cause. The phrase implies there's one, singular, and that finding it completes the job. Real incidents rarely oblige — a typical outage involves a config change that was valid but unusual, a validation step that only ran in CI, an alert routing to a dead channel, and a runbook written before the service was sharded. Remove any one of those four and there's no incident. Which one is "the" cause? None of them. All of them. The question you actually want to answer is: which of these can we fix before the next person inher
