As an outside IT specialist, we can get called in on some dangerous missions. Fixing a network is always a unique challenge. But when angry people on both sides get their guard up, you could be walking into a minefield. It takes more than technical skill to get the job done in that situation: you need to be a recognized authority who can take command of the situation, using more than a dash of diplomacy.
It was just after O-900 hours when we got the call to mobilize for a network assessment. The initial mission briefing from the newly-hired IT director seemed simple enough: the network was constantly breaking down. Employees were losing valuable time because their apps and files were constantly crashing. Their basic IT infrastructure was misfiring.
When I arrived on the scene, it was clear the company had already been through the meat grinder. Morale was low, all the way down. It turned out they’d been fighting with this frustrating problem for over a year, after implementing an expensive network that cost them half a million dollars. The CEO was in a mood to fire everyone on their internal IT team.
Emotional intelligence: the secret weapon for attacking a network engineering problem without it blowing up in your face
There might as well have been barbed wire and sandbags between the office of the IT director and the cubicle of the lead technical resource in charge of the network. The problem had started virtually from the day the IT director was brought on board.
His network resource staffers seemed lost, only semi-cooperative and constantly in a defensive mode in any conversation. The typical response from that lead resource whenever something was going wrong: “It works when I do it, so you must be doing something wrong.” Naturally, that didn’t fix the problems that were coming in fast and furious, every day.
The IT director and I had never met before, so for that first meeting, my goal was to listen and find out what he thought wasn’t working. I wanted to learn as much as I could and just be clear with him about how I operate. The method is simple: knuckle down with research, map everything out, compare their IT network practices to best practices and finally see if things were overdesigned or underdesigned. I wasn’t there to sell something, but find out what the problem was so we could fix it.
Listening first was key. His whole body language changed as he vented his frustrations. Eventually he seemed to relax just a bit as he realized he had the right person and that this problem was going to get resolved.
My primary mission was clear by the end of that meeting: find out how the network was structured and propose how it should be structured, so that the problems would disappear. My secondary objective: assess the skills of this lead network resource and determine whether he really had the skills to get his job done.
Now it was time to meet the lead resource. There were probably a dozen people on the team, but this was the sole person in charge of the network. I knew this person would be on the defensive. I had to get those defenses down.
“I’m not here to criticize how this network was implemented,” I explained. “I’m not here to look at how these support issues are getting approached or resolved. I’m just here to look at the network design. Any solution that comes from this is going to be a collaborative effort.” That wasn’t entirely true, given my assignment had a wider scope than I let on. Still, I had to make this lead resource feel like I wasn’t there for his head if he was going to share any reliable intelligence.
The conversation improved from there, but after many months of fending off attacks and insinuations regarding his performance, he was still on guard. As an outside IT specialist, you can’t just come in with a frontal assault and command this sort of person to bend to your will. You’ve got to be subtle, listening, asking probing questions that show off your technical expertise without stepping on their toes. It’s about ultimately leaving an impression that you know what you’re talking about.
By the end of the day, I’d established rapport with both sides. Now we could really start marching forward.
Declaring victory in the network engineering war: a win for both sides
By the end of the engagement, the real crux of the problem was clear: a third-party vendor had provided the company with an overly-complex design that would leave a single operator struggling to manage. The lead network resource was essentially put into a situation where it was impossible for him to troubleshoot. This is what led to network problems, complaints and frustration.
We understood the obstacle. Now the CEO provided the resources for the company to get past it. We proposed a greatly simplified network architecture and it was implemented in six months with almost zero downtime during the transition. When employees came in on the Monday after we’d implemented it, everything worked perfectly. As well, the IT director and the lead technical resource were at peace.
Vendors and engineers can overcomplicate networks and other technical solutions. They’ll propose big solutions, without thinking about how it will be implemented and supported. Sometimes, that can put people who should be on the same side into opposing camps.
That’s why we’re here, helping companies to find the easiest, most cost-effective solutions to their IT headaches – and sometimes, bringing peace to a conflict zone in the process.
Is your company’s leadership team and IT staff ready to go to war? Give us a call
