If Sun Tzu had worked in Tech Support, he might have opined ‘If you know your users and know your IT department, you need not fear a thousand PC outages.’ Business Reporter’s resident U.S. ‘blogger Keil Hubert is using martial and pop culture analogies to teach young job seekers how to become corporate IT troubleshooters.
If there’s one thing I learned from spending a dozen years working on a Navy base, it’s that sailors get livid when you call their warships ‘boats.’ If there’s one thing that the sailors learned in turn from us soldiers, it’s that we really enjoyed winding them up (I know I did). I love reading about Naval history, watching Navy war movies, and reading Navy-themed historical and science fiction stories. That said, I also love messing with my colleagues. That said, it’s about camaraderie not disrespect. Heck … if the sailors at my town’s recruiting centre hadn’t been in a closed-door meeting the night that I dropped by to ask about enlistment options, I might have spent my military career as a ‘squid’ instead of as a ‘grunt’ and a ‘zoomie,’ respectively. [1]
Along those lines, I noticed that the guys that my son works with at our local builders’ supply store were all forced to take unskilled labour jobs (like stocker, freight handler, etc.) to help pay for university even though there are a bunch of entry-level IT jobs going unfulfilled in our area. I’ve known many of these guys for years, and I know that they all have respectable computer skills. I was curious why they didn’t go after higher-paying, less strenuous, skilled positions. They said that they weren’t even applying for white collar positions because they couldn’t imagine getting accepted since they had no idea how the corporate IT world functions. That struck me as a Catch-22; they didn’t qualify for the entry-level position because they hadn’t already held the job …
As someone who has hired hundreds of people just like these guys, I knew that they were dead wrong. IT teams constantly bring young kids with raw talent aboard and turn them into technologists through a combination of technical education, on-the-job training, and cultural immersion. I decided to dust off my old ‘introduction to tech support’ course notes a few weeks ago and began converting the old curriculum into a seminar-style program that I could teach the guys after I got home from work … and before the guys had to leave for the night shift.
It’s honest work. I respect that. But what if there was an equally-honest alternative that paid three times as much, came with health benefits, and didn’t require painkillers after the end of every shift?
The original content covered a bunch of IT skills that I’d written back when I ran a military IT department. Back in the Air Force (a.k.a., ‘zoomie-land’), we used to train and certify ordinary office workers to perform diagnostics and repair work on computers, printers, and phones, to help reduce our field techs’ workload. When these ‘additional-duty troubleshooters’ finally called our Service Desk to request help, the diagnostic work they’d done made it possible to move their issues straight to the front of the work queue. The training program worked: we significantly increased our ‘first touch resolution’ metrics and decreased the number of support calls that got hung up in the system.
I figured it’d be possible to demilitarize the old content and convert it into a sort of ‘IT sector orientation’ course. It turned out to be a lot more work than I’d projected, but it’s been worth it: the students that volunteered to help test the course content for me have been highly encouraged by what they’ve learned so far. They’re gaining the confidence that they need to walk into an interview for a corporate IT role and get hired as an apprentice technologist. This is encouraging. Once we get this fully converted and optimised, I should be able to start teaching it to our older Boy Scouts.
The conversion process hasn’t been straightforward, though. A surprisingly large part of the conversion has involved replacing all of the service-specific jargon and metaphors with references that normal civilians will recognize. Many of the mental models and common references that we taught to military students simply don’t translate. That obstacle has required me to invent a bunch of new analogies and metaphors to help explain the fundamental concepts behind IT work.
This last week’s lesson focused on how IT departments are structured and staffed based on the size of the overall company. In the military, this is a non-issue and didn’t need to be taught; every Wing has an IT support squadron embedded in it, for example, that maintains all of the commercial IT kit. All we had to teach in this block was where to find the It squadron and what the Service Desk’s phone number was. Easy.
That wasn’t going to work for people who want to work in the private sector. In the commercial world, every IT group is different – they’re grown by happenstance as the parent company expands and contracts. I had to throw out 99% of the old content and write new lessons plans, student handouts and slides explaining how IT groups grow and add functionality over time. This included explaining what the various divisions, departments, groups, and shops actually do, and why they’re arranged the way that they are. I turned a 15-minute blow-off lecture into a 90-minute deep dive.
The reason why I insisted that new troubleshooters need to know this is because the way one’s IT group is organized determines whether your issue will get fixed or whether you’ll get your time wasted. To most users, the IT arm of the company is a ‘black box;’ a request goes in, and sometime later, someone might attempt solve your issue. Everything about the job’s triage, routing, and handling is conducted behind closed doors. Once a trouble ticket is submitted, it may as well have disappeared. It’s location, status, disposition, and owner all become obfuscated.
I likened this process to classic war movies like The Hunt for Red October and The Enemy Below … It’s like a warship trying to guess what a submerged submarine is doing. The heroes know that the enemy sub wants to attack the slow and vulnerable cargo ships that the destroyer is escorting, but it can’t attack with impunity; once the sub fires, the destroyer can pinpoint its location and destroy it. Or they can try and destroy the sub pre-emptively by firing on where it’s hiding, but every missed shot consumes previous ammunition and gives the sub a chance to sneak away into a new position. It’s a deadly game of cat-and-mouse played in pitch darkness. [2]
In war stories, the surface combatant heroes have the advantage of speed, superior firepower, and situational awareness, but they can’t see the submarine while its submerged. They can only guess where it is, what it’s up to, and what its intentions are. The (allegorical) sub can see them, though, and gets to decide where, when, and how to engage. The heroes can do little more than fire off shots at featureless and silent ocean, hoping to get a near-hit through random chance until and unless the sub makes itself known. It’s infuriating, and the waiting only makes it worse. [3]
Everyone involved takes the game deadly seriously, because the price of failure is too damned high
The reality of tech support is that it’s not very dramatic (like sub hunting in movies). If anything, it’s confusing, boring, and often resolved through dumb luck rather than via technical brilliance (also … in its own way … like sub hunting in real life). Most new trouble tickets are routed to the wrong office, where they’re then either punted randomly to a different workgroup, or else get botched by a well-meaning tech using the wrong protocol. Small wonder, then, that many trouble tickets never get satisfactorily resolved.
More importantly, the mysterious, skulking ‘other’ in the analogy isn’t an aggressive enemy; IT departments exist specifically to help keep the business running, not to destroy it. So, the destroyer-versus-submarine idea wasn’t ideal. That’s fine; it wasn’t meant to be perfect model. Just functional.
The core concept behind the analogy was that the business office that the troubleshooter supports is like the destroyer: the troubleshooter knows the equipment, people, and processes affected by the issue. They know how the process is supposed to run, and what the ‘normal’ state should look like. That gives the troubleshooter a huge advantage in assessing whether or not repairs are successful. On the other hand, both the experts and the core systems that make the affected equipment run are almost completely invisible to the troubleshooter and the users.
In a start-up or a small company, this usually isn’t an issue. It’s easy enough for a frustrated user to stomp over to the IT guy’s desks, grab him by the ear, and march him over to where the broken piece of kit is located. Also, the repair tech can be … incentivized … to address the problem immediately.
Even the most gentle of souls will consider punching a co-worker when the e-mail server goes wonky
This usually isn’t the case in a medium or larger company, where the IT department is out of sight, and is often completely opaque to the people that it serves. Once the troubleshooter tosses the support request over the wall to the Service Desk, there’s no way to tell who’s working on the job, what’s they’re working on (or if they’re working at all), or how effective the attempted repairs might be. The Troubleshooter and affected user have to wait patiently until the affected device suddenly starts working again (assuming that it does). I’ll cover this part of the curriculum more in next week’s column.
Anyway, this is why it’s so important for a would-be first-tier tech support agent to understand the dynamic in-play between the user community and the IT department. This dependence on mysterious ‘others’ can be infuriating, especially when system outages threaten to leave the affected user unable to perform his or her primary job. This sort of experience breeds resentment and even loathing for IT folk, even when the IT folk haven’t deliberately done anything to offend. The disconnect between service consumer and service provider strains internal relations. Users hold grudges when their problems aren’t solved quickly and/or effectively. That can lead to users (especially senior users) lashing out at IT whenever they get the opportunity – which creates a self-fulfilling prophecy: users don’t expect IT to serve them well and therefore treat IT people awfully, which causes IT people to provide substandard service, which reinforces negative expectations, etc.
Knowing all of this, a good troubleshooter can take pre-emptive action to interrupt the negative cycle before it gets out of hand. First, the troubleshooter can get ahead of the Service Desk and perform all of the required diagnostics checks and simple fixes that a field tech or phone tech would use for early Root Cause Analysis. Pushing the results of those actions up to the Service Desk will greatly reduce the number of potential escalation points that the Service Desk will need to route the job to. Consider it ‘accelerated triage.’
Another way to build credibility with the Service Desk is to make all the stupid non-issues go away quietly. If you can keep Janice in Accounting from calling in a bogus angry complaint every Monday, that’s worth a heap of goodwill from the harried triage techs
Also, knowing the IT Department’s internal structure helps the troubleshooter to check in regularly with the servicing teams to coordinate hands-on actions, check on statuses, and keep the users informed (rather than waiting on the Service Desk to make such arrangements or notifications). By actively managing the relationship, the troubleshooter gains credibility in the eyes of both the user and the Service Desk, while simultaneously expediting the processing of the job. Everybody wins.
This is what I want for these students over the long run: to be useful enough for their company that management will be eager to invest in their professional and technical education. They may not have the corporate tech skills that they need walking into the interview, but if they have the right mind-set, a solid understanding of the environment, and a declared motivation to vigorously manage the relationship between users and IT, thought ought to be incentive enough for a smart hiring official to take a chance on them. After that first break, they can earn their next step up the corporate ladder through hard work and charm.
[1] These are playful insults that that American service members use to chide one another. I don’t recommend using them if you’re not one yourself.
[2] This story is a classic dramatic standoff, and lends itself to multiple genres. The best episode of the original Star Trek television show – 1966’s Balance of Terror – was arguably a direct translation of The Enemy Below set in space.
[3] Admittedly, getting your broken printer fixed isn’t nearly as gut-wrenching as being hunted by a lethal skip killer during wartime. At least, it isn’t for most people in most companies.
Title Allusion: D. A. Rayner and Wendell Mayes, The Enemy Below (1956 Book and 1957 Film)
Photographs under licence from thinkstockphotos.co.uk, copyright: naval ships – Dovapi; forklift truck – Nordroden; angry worker – MangoStar_Studio; pc doctor – AntonioGuillem
POC is Keil Hubert, keil.hubert@gmail.com
Follow him on Twitter at @keilhubert.
You can buy his books on IT leadership, IT interviewing, horrible bosses and understanding workplace culture at the Amazon Kindle Store.
Keil Hubert is a retired U.S. Air Force ‘Cyberspace Operations’ officer, with over ten years of military command experience. He currently consults on business, security and technology issues in Texas. He’s built dot-com start-ups for KPMG Consulting, created an in-house consulting practice for Yahoo!, and helped to launch four small businesses (including his own).
Keil’s experience creating and leading IT teams in the defense, healthcare, media, government and non-profit sectors has afforded him an eclectic perspective on the integration of business needs, technical services and creative employee development… This serves him well as Business Technology’s resident U.S. blogger.
