Should IT Managers Assume Good Intentions When Developers Mess Up?

We had a classroom full of partners excited to learn about our new software product. What we were missing was the instructor – Steve.

Unfortunately, this was not a big surprise. He had a suspect track record having been late a few times in the past. But he was REALLY late this time and the techies in the class were starting to get restless.

I had just asked one of Steve’s buddies if he knew where he was. “Sorry, I’m not his keeper,” was the edgy response. Even his friends on the team were getting a bit frustrated with Steve.

I tried to call Steve again and again. No response.

Finally, one of the other developers offered to teach the class and the crisis was averted. She wasn’t nearly as talented an instructor as Steve was, but beggars couldn’t be choosers.

As Steve’s manager, I had a choice to make. Before I delve into that, let me ask: if you were Steve’s manager, what would you have done?

First ask yourself, when someone on your developer team screws up, what is your immediate thought? How much of your first reaction is driven by past performance?

And how much of it is driven by your personal past experiences? How about company culture?

It is normal to consider all those things before you form a response. But if you are really ticked off in the heat of the moment, don’t you just want to scream at the person - something like, “What were you thinking!?!?”

Or worse – “You’re fired!”

Let’s face it. People screw up -- some more than others. Screw ups could be a result of poor choices, bad planning, insufficient skills, unexpected circumstances or simply bad luck.

But should your first reaction be “I’m going to ring their neck?” or should it be “Let’s get the facts?”

For situations like these, a manager of mine taught me something valuable that I believe should be at the core of any company culture. His philosophy: always first assume good intentions.

The problem is, I have found this doesn’t come naturally to people and isn’t inherent in most company cultures. This especially goes for IT departments where the smallest problems can quickly escalate to a larger crisis with lots of finger pointing and raised voices.

Therefore, it is incumbent on the manager to take the expectations of good intentions to heart and work at making it their first reaction when a problem occurs.

But what if there is a history of problems with the person? What if they person doesn’t care how their mistakes impact the team?

In other words, what if the guy is just a jerk?

All fair points, but there are good reasons to maintain composure and always respond consistently to first manage the problem through to a resolution and then follow up with the fact gathering to find out what happened and work to prevent it from happening again.

Start off by asking if the person in question understood the assigned task. Were the instructions clear? Did they understand the priority of the assignment?

I always like to have a team member repeat what is expected of them to ensure there isn’t a miscommunication. Not everyone likes this because they at first feel like their knowledge is being questioned. And guess what – it is! But once they see everyone treated the same and that the context is positive, there usually isn’t a problem.

Another consideration is their training and experience. Did they have the skills and training necessary to accomplish the task?