I just listened to “Troubleshooting Agile”, a new audio series from CTO Craft contributor Douglas Squirrel and his podcast partner Jeffrey Fredrick. The first edition is on blameless culture, which I think is a great starting point: it’s very difficult to develop, and taking baby steps toward that in a team which doesn’t have it often feels wrong.

Isn’t it interesting how most stories about “blame” in a technical setting revolve around database changes in a production setting. I have a very similar war story in this regard: I had already been running a relatively blameless culture for a while, when I got a similar ‘phone call (I say “relatively” because I don’t think you can achieve it in absolute terms – this is largely a technicality, though).

In my case, it was a development tool being run in a production environment, causing data destruction to live data. I’ve talked about this example before and the technical and process failures here were actually very subtle; however, the first benefit of blamelessness here was clear. I got the call early, and the engineer had already shut down the live service involved to prevent more data loss.

This is important in two regards: first, the engineer here felt empowered enough to hold up a red card and stop a live service. This is an important Modern Agile tool, related to safety in the team. Stop Work Authority is a high level of responsibility, and you cannot use this tool if you have a culture of blame.

Second, when an engineer knows there is no culture of blame, they’re incentivised to take the right decisions. If they expected a punishment instead, I would be encouraging them initially to either attempt to cover-up the problem or otherwise resolve it, which would push back getting more help.

I will say, blameless running is absolutely the right way to go – there are literally no downsides to this approach. However, Jeffrey and Douglas didn’t talk very much about how you implement it! Here’s my approach.

Blame versus Ownership

I’ll be clear up-front that “blame” and “ownership” are totally different concepts. Blame is bad, but ownership is pretty good. You have to be extremely careful not to throw the baby out with the bathwater when removing blame from your team: you can also be encouraging them to avoid ownership.

As an example, “I did something stupid” isn’t (to me) necessarily an indication of accepting blame: it could be a self-deprecating way of accepting ownership of a decision. It’s a very different statement than “You did something stupid” (although I could write a whole ‘nother blog post on judging the quality of decisions!).

Similarly, “The process failed me” might be a blameless statement. It could also be a statement that disclaims ownership, though, and therefore could be dangerous. Simply moving blame from people to inanimate things also isn’t a blameless culture. “The process failed to stop me!” is actually just another way of blaming our past selves, which is not much better than blaming our current selves.

Taking ownership is an important way of ensuring that blame doesn’t get distributed in a team: we don’t blame others. If the buck is with me, that’s where it stops. Being blameless isn’t just about not saying “This is your fault”, it’s also about:

• not finding excuses;
• not denying problems exist;
• swallowing pride when necessary;
• being honest.

I tend to find that a blameless culture follows as a necessary postcondition of enacting a culture of ownership. This is how I recommend people enact blamelessness: look for it as a side-effect as a positive move to encouraging ownership.

I also believe that simply removing blame is quite difficult if you don’t replace it with something, and actively provide people with a positive mental model to frame their approach to problem solving. Ownership mindset is a great replacement.