Why Corporate IT is Broken - Playing the Blame Game

The "Why Corporate IT is Broken" series is a collection of blog articles originally intended for a low-cost eBook. It may go ahead one day!

• "You didn't explain the requirements properly."

• "You should have known what I meant."

• "Why didn't you do that?"

• "Who is at fault for this?"

Who can honestly say they haven't heard one of these statements or questions or even been guilty of saying them. They are words, when uttered, are a way of pointing a proverbial finger at someone (or at least, at someone else), to shift blame. What is the benefit of this at the time when something is broken or not working as expected?

The need to blame is a negative reaction to the frustration that something is broken.

I sat on a call between 2 companies, where they bickered because one company thought the other should have done something a certain way and was very pointed in their wording that they hadn't received what they expected. Meanwhile, the other company was also very blunt that they never stipulated how it would or should be delivered and had worked extra hours to complete the work. It was escalating quickly so I said something that left an awkward silence... "Team, we can play the blame game later if you want, but for now, we have a problem so let's focus on fixing it." After a few seconds the most senior person on the call responded, "Agreed".

Funnily, when the issue was resolved, nobody felt a need to return to the blame game. Everyone was happy it was solved. In the absence of an issue, the aggression faded.

The response to blame is a negative reaction that stifles the desire to fix what is broken.

A server stopped working one day. It was impacting a whole building of people. I sat on a call with the company "incident management" team (senior people, vendor contacts from the IT company, the telecommunications company, stakeholders etc.) A telecoms technician had been in the server room patching a network port the night before so I suggested, since the technician was in the building anyway, that they rule out a network issue from accidentally bumping the patch cable first. The telecom company head was adamant that there was no evidence to suggest they were to blame so refused to allow the technician into the room to check. The IT company tried everything to connect to the server but could not. After half a day, I was granted access to the server room and found that the patch cable for the server was directly above the patch cable the technician had connected the night before, and it had been bumped, causing a disconnection. I pushed it back in, the server came online, the IT department and business were happy... and the telecom manager was embarrassed. Had he not been so defensive at the idea they were at fault, the issue would have been solved half a day earlier.

Technology and business domains are both guilty of this.

Tech-people blame non-tech people for not explaining things properly or not understanding tech well enough. Non-tech people blame tech people for misinterpreting requirements or making things too complex. This leads to poor culture, frustrated staff, and perpetually unideal solutions.

But there are a few ways a business can improve this:

• When there is a problem, focus on finding a solution as a priority

• Work together! Use agile delivery methods like scrum to bring tech and business domains to a single team when designing and implementing new things

• Take the time to understand each other’s work and processes, even at a high level

But most importantly, stop playing the blame game.