I think a lot can be learned from Post Mortems, but I’ve found in practice they can be inefficient ways to move forward.

The purpose of a Post Mortem is to analyze a situation in order to improve underlying processes or knowledge. It’s one of those meta-meetings about work. However, I think a perfectly acceptable outcome of a Post Mortem is that a team does nothing.

Let me explain.

When things go wrong, I think it’s good to analyze them. The team needs to be careful about preventing blaming, however; when Post Mortems assign blame to individuals, they sour a company culture. At one company I worked for, a Post Mortem at a large enough scale could be a signal that someone was going to be fired.

After analyzing what went wrong, the team asks what could have prevented the error. An improved process? An extra step in a process? An entirely new process? Better information systems?

Processes are extremely useful tools for any organization. However, at prior companies I’ve worked for, there seemingly was a lot of process bloat. Some of these processes are vital to maintain reliability of our sites, but even these processes could fail. I remember when an engineer brought down an entire database since they clicked through the warning messages too quickly before pushing code. This was considered a great process, yet it also failed.

To prevent the creation of too much process, it is imperative that a team then analyzes how painful the problem was. Does it happen often, and is it really painful? If the solution to preventing this problem in the future is an additional process, perhaps the cumulative time spent doing that process over the next decade is not a good tradeoff for preventing an unlikely and not painful error.