How to Run a Post-Mortem That Actually Fixes Culture

Most post-mortems find the wrong thing.

Most post-mortems fail. They fail because they look for the wrong thing.

When a system breaks, a project fails, or a major bug reaches the customer, the immediate reaction is to find out who caused it. The team gathers in a room or on a video call. They look for the person who made the bad call. They look for the line of code that broke the build. They look for the decision that, in retrospect, was clearly wrong.

They write it all up. They assign a “lesson learned.” They file the document somewhere in a shared drive where no one will ever read it again.

Then, the exact same thing happens again three months later.

Why? Because nothing in the environment actually changed. You found the person who made the mistake, but you did not fix the system that made the mistake possible. You treated the symptom, not the disease.

This template runs a different kind of session. It is a different kind of post-mortem. Instead of asking who made the mistake, it asks a much more powerful question: What in our environment made that choice feel like the right one at the time?

That single question changes everything about the conversation that follows. It moves the team from blame to curiosity. It shifts the focus from human error to system design. And most importantly, it actually fixes the culture.

In this guide, we will break down exactly how to run this new type of post-mortem. We will use simple steps, clear questions, and a proven four-part structure. By the end of this guide, you will have a complete “patch” to fix your broken review process.

---

Why traditional post-mortems break trust

Before we fix the process, we need to understand why the old process is broken.

Think about the last time your team had a major failure. Maybe a server went down on a busy sales day. Maybe a product launch was delayed by two months. Maybe a key client cancelled their contract.

How did the team react? Usually, there is a moment of panic. Then, there is a search for a target.

In traditional post-mortems, the hidden goal is often to prove that it was not my fault. People bring logs, emails, and chat messages to prove they did their job correctly. They point fingers at other teams. They say things like, “Well, I told the design team we needed the assets by Tuesday, and they sent them on Thursday.”