A lot of folks in my homeowners’ association’s Facebook group are angry. Their electric bills have gone up, and they think they know the culprit — and it’s not the excessive heat wave. No, it’s the new meters our electric company has installed. The new meters make their bills higher. The new meters shorted out their air conditioners. Someone needs to pay damages. Should we consider a class action lawsuit?
Maybe my neighbors are correct, and the new meters are a problem. I don’t know. What the incident made me think about was blame. Anytime something goes wrong, we’re so quick to blame someone. Some are even quick to blame themselves, whether justified or not.
I once gave a presentation on Agile methodologies and Scrum to a group of not software developers. When I was finished and opened the floor to questions, the very first question was from an executive who asked, “What do you do when a squad doesn’t meet their commitment?” His tone made me feel his real question was, “When a squad doesn’t meet their commitment, how are they punished?”
Blame in Complex Systems
I’ve been reading The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations by Gene Kim, Jez Humble, Patrick Debois, and John Willis. “DevOps” is a software engineering culture in which the people who write the code and the people who run the servers work closely together instead of being siloed into separate divisions.
The authors make some insightful points regarding complex systems, which are defined in part as a system that “defies any single person’s ability to see the system as a whole and understand how all the pieces fit together.” Examples include many major software projects, automobile manufacturing, or, heck, daily life.
Despite all best efforts, things go wrong in complex systems. Accidents occur in factories. Twitter goes down. Peter fails to fill out his TPS reports correctly. Stuff happens. And after it happens, we point the finger, and we blame someone.
What if there was a better way?
An Opportunity for Learning
The authors of The DevOps Handbook write that in a DevOps culture, “When failures and accidents occur, we treat them as opportunities for learning, as opposed to a cause for punishment and blame.”
Opportunities for learning. Not causes for punishment and blame.
The DevOps Handbook is about software engineering culture, and I can think of a lot of times in my career when I wish I’d have worked more in a culture of learning instead of a culture of blame.
But think bigger. Remember: daily life is a complex system.
What if we all stopped pointing the finger? What if we all stopped assigning blame? What if we all started asking, “What can we learn from this?”
We’d all be a lot less afraid to make mistakes. Don’t we idolize folks who fearlessly pursued and attained lofty goals despite a high risk of failure? Wouldn’t society benefit from more of those kinds of people?
We’d learn a lot more about how to prevent future failures if the people responsible had no reason to feel ashamed, and therefore no reason to hide or obfuscate their actions. Instead, they openly shared what happened — successful or not — in the interest of knowledge sharing, knowing their admissions weren’t going to be used against them.
And above all, it’s kind
There are certainly times when punishment is necessary. No one needs me to list them. But there are far more failures in life that should be treated as opportunities for learning than should be treated as causes for punishment and blame.
A great man once put it this way:
“I’m not trying to win. I’m not doing this because I want to beat someone, or because I hate someone, or because I want to blame someone. It’s not because it’s fun. God knows it’s not because it’s easy. It’s not even because it works because it hardly ever does. I do what I do because it’s right! Because it’s decent. And above all, it’s kind. It’s just that. Just kind.”