The Postmortem Was Written. But the Real Story Stayed Private.

Why blameless culture isn’t about removing consequences — and why even the best process can’t replace the human dimension of accountability.

I was brought in to investigate an incident I didn’t cause.

A colleague had made a mistake. Serious enough to impact users, serious enough to escalate to leadership. The investigation fell to me — find the root cause, understand what broke, design the fix.

I did the work. I traced the timeline. I found what failed and why.

But something unexpected happened along the way: my own sentiment toward that person shifted. Quietly. Without me choosing it. I knew it wasn’t fair. I knew the right thing was to separate the person from the problem. I knew that’s exactly what a good postmortem is supposed to help a team do.

And yet.

My colleague was honest about what happened — but not in a document. He went directly to our head. Privately. To explain. To apologize. Because a direct conversation felt more human than a formal document.

I understood why. And that’s what stayed with me.

What Blameless Actually Means

The concept of blameless postmortems didn’t originate in tech. It came from healthcare and aviation — industries where mistakes can be fatal, and where the cost of silence is higher than the cost of admission. Google’s SRE team brought the practice into software engineering and made it foundational: a blameless postmortem must focus on identifying the contributing causes of an incident without indicting any individual or team for bad or inappropriate behavior [1].

The keyword there is contributing causes. Not the person. The system that allowed a person, with good intentions and incomplete information, to make a decision that led to failure.

This framing matters because of what happens when you remove it. As the Google SRE Book puts it: if a culture of finger pointing and shaming individuals prevails, people will not bring issues to light for fear of punishment [1]. The result isn’t accountability. It’s silence. And silence doesn’t prevent the next incident.

But here’s what I’ve noticed people get wrong about blameless culture: they think it means no consequences. It doesn’t.

Accountability and Blameless Are Not the Same Thing

Gergely Orosz, in his research on incident review practices across more than 50 engineering teams, puts it directly: accountability and a blameless culture are two separate things that can — and do — go hand in hand [2].

Accountability means people take responsibility for their work. When things go wrong, they take ownership of fixing it. That’s not optional.

Blameless means you recognize that it’s counterproductive to fault someone for doing something they were unaware would cause an issue [2]. The focus shifts from who touched it last to what conditions in the system made this possible.

The Google SRE Workbook frames the same principle at the organizational level: introducing postmortems into an organization is as much a cultural change as it is a technical one [3]. You can have the best template in the world. If people don’t feel safe being honest in it, you will always get the sanitized version.

And sanitized versions don’t prevent repeat incidents.

Why My Colleague Chose the Private Path

Going back to that incident: my colleague was accountable. He admitted what happened before anyone found the root cause. He apologized to the person who needed to hear it.

But he did it privately — not in the document.

He didn’t bypass the process out of dishonesty. He bypassed it because the conditions for that kind of honesty hadn’t been established. And that’s not unique to one team or one company — it’s the default state for most organizations that haven’t actively built it.

So he chose the path that felt more human: a direct conversation, an apology, a closed loop between two people. And honestly? In that moment, for that relationship, it probably was the right call.

But here’s what that means for the organization: the RCA existed. The timeline was accurate. The technical root cause was documented.

The why — the full context of what that person knew, what pressure they were under, what they were trying to do — that stayed in a private conversation.

That’s a gap most teams never notice. Because the ticket gets closed. The monitoring goes green. Everyone moves on. The system looks like it learned. But it only learned half the lesson.

What a Postmortem Is Actually For

A postmortem isn’t a report. It’s a learning artifact.

The Google SRE Workbook describes it this way: a truly blameless postmortem culture results in more reliable systems [3]. Not because the document exists — but because people felt safe enough to put the real information in it. The real timeline. The real decision points. The real pressures that shaped what happened.

When that information stays in private conversations instead of shared documents, two things happen. One: the organization can’t learn from it. Two: the next person in a similar situation has no record that this moment happened, what was actually going on, and how it resolved.

The Google SRE Book also notes that postmortems should assume that everyone involved had good intentions and made the best choices they could with the information they had [4]. That assumption has to exist in the culture before it can exist in the document. You can’t template your way into psychological safety.

What This Means If You’re Building Toward Remote or International Teams

Remote engineering teams run on async documentation by default. There is no hallway conversation. There is no quick sync where someone can read the room. There is no private path to leadership that doesn’t leave a trace.

In those environments, written records are the operating model — for decisions, for incidents, for how systems evolved and why. An engineer who knows how to document incidents honestly, who can write a postmortem that is specific and blameless and actually useful — that’s a meaningful differentiator. Not because it looks good on a CV.

Because reliable systems depend on teams that can learn from failure without making learning costly.

Where to Start

If you’re in a team without a postmortem culture: start with one incident. Write the timeline. Write what you knew at the time. Write what you would change about the system — not the person.

If you’re in a team that has a postmortem process but the documents always feel thin: that’s a signal. The form isn’t the problem. Ask whether people feel safe writing the real version.

And if you’re the person who caused an incident and is wondering whether to write the truth in the document: the answer is almost always yes. The fact that it feels hard is exactly why it matters.

Documented failures age better than private ones.

The system can only improve on what it can see.

References

[1] Google. Postmortem Culture: Learning from Failure. Site Reliability Engineering Book. https://sre.google/sre-book/postmortem-culture/

[2] Orosz, G. Incident Review and Postmortem Best Practices. The Pragmatic Engineer. https://blog.pragmaticengineer.com/postmortem-best-practices/

[3] Google. Postmortem Culture. The Site Reliability Workbook. https://sre.google/workbook/postmortem-culture/

[4] Google. Production Services Best Practices. Site Reliability Engineering Book. https://sre.google/sre-book/service-best-practices/

Cristian Stevanus is an IT Infrastructure Engineer writing about cloud, SRE, and the practical side of building reliable systems.