Stop Talking About Blameless Postmortems

In tech, we talk about “Blameless Postmortems.” What does this mean? Why are we talking about blame?

I think the phrase “Blameless Postmortem” has a strong connection to git blame, the command we use to find context on what work was done together and who wrote the code. git blame shows you who changed which lines and when. It gives you context on the current state.

Origins of Blame

North American culture has an innate belief in individuality and hard work, which comes from the Puritan culture that our capitalist economies are built on. We believe individuality and hard work have built the success of our countries. At least, that’s the cultural narrative.

As a part of that, individualism comes with blame. Whose fault is this? It’s not mine, it must be someone else’s. Puritanism takes “blame” so far as to make us believe we need to work hard to make up for our innate faults.

Success in this culture is working so hard that you overcome your innate weaknesses as a human.

Each individual must labour away their weaknesses.

This is my take, at least, on the origins of blame in North American culture. I think it has to do with innate cultural beliefs about hard work and individuality.

git blame

The git command itself has an interesting history.

The short story is that it ended up in git because it was in SVN, and blame seemed to be a short word that carried strong meaning. In line with the culture that created rather blunt commands like kill, dump, and strip.

I think there is a good possibility that the innate culture of programming at the time was blunt and individualistic. blame was a good word because we want to know who wrote this. annotate didn’t take off because it’s ambiguous about what it is doing. What is it annotating? What are these annotations?

I’d prefer git context because it shows the context in which lines were modified together. I don’t care that much about who did it, unless I need help understanding it. However, many bugs occur because one line was written a few months or years ago, and another conflicting line was written yesterday. It is hard to “blame” anyone when you have this context.

A Responsible Postmortem

Now that you’ve followed the bunny trail of Puritanism and blame with me, let’s get back to postmortems.

We often talk about “blameless” postmortems, which puts the word “blame” at the forefront. It creates a culture where no one wants to assign responsibility, and everyone can say, “Well, no one is to blame here; code is just hard, I guess.”

We need “Responsible Postmortems.”

Responsible postmortems understand the context in which the code was written, and they respect who owns the code and what needs to change to reduce the impact of similar errors.

In a Responsible Postmortem, I would talk about my actions that led to the incident. My colleagues would discuss how they contributed, and we would diagnose the cultural, technological, and systemic changes we need to prevent a similar incident in the future.

Responsibility is about knowing that, as a team, we approach our work with good intentions and are working together to build great things. We know that building great things comes with complexity, and we are excited to tackle that complexity together.

Building Great Things

To build great things, we need a culture that is energetic and creative. That encourages exploration, discovery, and synthesizing information into new findings.

“Blame” drags people down and makes them afraid of taking risks.

“Blameless” postmortems are even worse. They allow teams to shrug off responsibility and drown in the overwhelm of complex code.

I try to create an environment where teams do not need to think about blame. We work to build things we’re excited about. The code is what it is. If you merge a bug, I’ll fix it. If I take the system down, we’ll get it back up together.

I am excited to build great things, including building teams that build shared context and ownership over the code we work with.