Dealing with An IT Bully

Comment on IT Bullies

“You are an idiot.” That was how I was greeted on an already gloomy, rainy Monday morning. I had just spent the weekend trying to help my team troubleshoot a production problem, missing a family event and getting little sleep. While I had ultimately resolved the problem, it was pretty apparent I wasn’t going to be showered with accolades.

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.

Granted, there was much pressure from top management to get this release out by Friday and thus documentation and any internal training were pushed aside. That being said, it turned out a major bug was in the new release and the on-call support engineer had run a baseline test, but couldn’t put the results in context with the new reality introduced by this new bug. His only recourse was to escalate, and do it quickly.

I pushed back and told Dirk that I didn’t appreciate his tone. I suggested we sit down with our manager (the CIO) and talk through the issue to avoid future problems. His brow furrowed and he raised his voice, going on and on about how the software team should just take over support, since my team was obviously incompetent.

At this point, I realized I was just beating my head against a brick wall. Having had these poignant discussions with Dirk in the past, I knew he was not a reasonable person.

What could I have done leading up to this confrontation to change things? What can you do proactively to address any bully you might work with?

Here are three ideas: First, try to establish a conversational relationship. Some bullies are mean and nasty at work, but are astonishingly normal outside of work. If you can sit down and explore things you have in common outside of work, it may temper outbursts at work.

I asked Dirk if he watched the SciFi Channel and he said only idiots had time for TV. Strike one.

Second, you may be able to win a bully’s respect by showing off your knowledge on a tough IT topic.

I mentioned to Dirk that I wrote an article about how to best manage a support team. He laughed and said “I cannot imagine anyone wasting their time reading one of your articles.” Strike two.

Third, try and find some intermediary to broker issues that start getting out of control. If your manager isn’t an enabler of the bully’s actions, when things got heated you could have the manager negotiate a settlement. Or find a peer that the bully had a better relationship with that was more reasonable to referee prickly conversations.

I asked the CIO to broker this support issue discussion who immediately dismissed it and said, “I pay you two enough to work these things out without involving me.” Strike three.

It turned out that nothing worked with Dirk. He was just not going to be an easy person to work with and it was apparent the CIO couldn’t care less if Dirk was causing an unpleasant work environment. I either had to leave the company or put up with his antics by covering my butt with excessive documentation of every conversation and action.

I eventually left because by the CIO enabling this behavior, more and more people in the company started acting like Dirk, causing an unproductive, confrontational workplace culture.

I would have been an idiot to have stayed.