Comment on IT Bullies

The lovely human being who greeted me that morning was our VP of software development, Dirk. At least I’m pretty sure he was human. I remember sitting there weary-eyed, staring at the smirk on his face thinking that I’d rather be at the dentist getting a root canal than having to listen to this blowhard spout off.

It’s safe to say that most of us in IT have encountered someone who was belligerent and unreasonable. For example, you may have worked with a person who believes they are God’s gift to information technology and are the ultimate authority on any IT topic.

These bullies are quick to aggressively divert blame for any problem back to someone else, because they couldn’t possibly be responsible. Some are passive aggressive, where they will subtly lay blame behind your back. Others enjoy getting in your face and being as confrontational as possible.

Let me continue and share my painful experience. Then I’ll take a step back and make some suggestions on how to deal with an IT bully.

Dirk was definitely not passive aggressive.

He continued to berate me. “Your support team doesn’t have a fracking clue, so you must not either.” I wish he had really said “fracking” because then I could have explored our potential inner-geek connection and diverted our discussion to that weekend’s Battlestar Galactica episode, where “frack” is truly used as a cuss word. We could have joked about he must be a Cylon, thus confirming my thought he was not human.

But alas, this was to be a totally humorless discussion.

Trying to maintain my composure, I asked him exactly what he was referring to. He went on about how his on-call developer got called at 3 AM on Saturday and that it turned out my support engineer hadn’t done basic troubleshooting. Dirk said that the problem was that my support engineers never follow escalation procedures, thus unnecessarily engaging the development team.

I hate when people say things like “never” when they know that this all-encompassing term is inaccurate. It was true my team had made mistakes in the past, but they also had performed admirably under less than desirable circumstances due to the instability of the software product we had to support.

He continued, “Your guy didn’t run a baseline test and then he didn’t document the issue in our case management system before escalating.” Now I knew this wasn’t an exaggeration, but we had discussed in past management meetings that when the production system goes down, immediate verbal communication between engineers was acceptable to expedite the issue -- as long as the managers were notified.

I had been notified and told my support engineer to escalate. When I tried to call Dirk, he didn’t answer, which is not surprising in the middle of the night. But he never called me back the entire weekend.

So in retort I said, “Dirk, we agreed verbal communication was okay in these situations. Why didn’t you return my call so we could talk through it?”

He responded, “I had better things to do than deal with an issue that should never have been escalated in the first place. Your team consistently wastes my team’s valuable time and I’m sick of it.”

Here is what really happened. The development team had put out a new release on Friday evening and my team received no training on the release. When I previously asked Dirk about knowledge transfer he had laughed and said any idiot should be able to figure out the new features on their own.

In retrospect, I know he was referring directly to me.