The Blame Game

I figured I’d take a break from my usual Tech piece with a bit of a rambling/conversational post today. Within the last few months several incidents have made me re-think this idea of blame and in particular, how I respond to being blamed.

In this one particular incident, I was the victim. A failed bamboo build job had resulted in several, team/project wide emails being circulated all with the subject header of…

“Awad, your last commit broke the build!”

At the moment, it took all my energy and restraint to not ‘Reply to All’ whilst demanding proof that I was the culprit. Rather, I refocused that energy in diagnosing the build. After all, defects aren’t one persons responsibility. But, in retrospect, this was primarily driven by the fact I do always seem to suffer from a little self doubt (which I believe to be healthy!)

With that in mind, I informed my delivery lead that I’d be spending some time diagnosing the build, and also added that I’d be timeboxing the task. And off I went investigating the issue. It came as no surprise to me that my commit was in fact not the cause of the broken build. What annoyed me however was I was able to come to that conclusion in a very short period of time.

As a general rule, at this point I would have replied back to that original email, CC’ed all stake-holders stating that it wasn’t my commit that cause the broken build and that would be that. But instead I opted for a different approach. I reached out to the fellow who sent the original email. I explained to him that it was not, in fact, my commit that broke the build. And further to that, I would be happy to work alongside him to find out the root cause and eventual fix to the defect.

In the end the problem was due to a breaking change that was made in a library that was part of one of the dependent services. This isn’t uncommon given that we both work in a microservices environment where each service has a dependency to 5 others.

With the fix out the way, he went on to explain that he himself has also been on the other end of the blame equation. He was so used to receiving those kind of emails that, for self preservation sake, he had also begun to send the same.

And I can empathise with him. A lot of times it is far too easy to start hand-waving, finger-pointing and email-sending especially when under the (illusion of) time pressures of a looming deadline.

Taking ownership and accountability of that bug wasn’t easy. Is it infantile of me to think that in that one incident I could have made a change in our culture for the positive? Maybe, but it sure felt rewarding and empowering when I stopped playing the victim and started taking action.

On the other hand, if my commit had turned out to be the cause of the broken build. Well… everyone makes boneheaded mistakes. I would have tried to fix it as fast as I can, and then tried to make sure that it doesn’t happen again. And in the end, I’m sure they will have respected me for it. Besides, nothing says sorry quite like buying the whole team a box of doughnuts!

1 Comment The Blame Game

  1. Nader Eloshaiker

    Hey Awad, when I was where you are at, I accepted that the blame game was the norm, heck I was probably guilty of it given that there was one “rock star dev” that habitually broke the build. However having moved onto other engagements, I have discovered that it actually isn’t normal at all but rather the culture that drove people to do it. This engagement I am at isn’t interested in who broke a build and all come together to fix an environment. It also helps that they have a stack that allows for rapid deployment too but at the end of the day, a broken build isn’t one persons problem to fix and if you can help, then do it. It’s not about bashing people with a big stick, these things can and do happen and rarely is it due to incompetence or carelessness.

    Reply

Leave a Reply to Nader Eloshaiker Cancel reply

Your email address will not be published. Required fields are marked *