Engineering skills aren’t nearly as important as people skills when you’re interacting with upset customers. Business Reporter’s resident U.S. ‘blogger Keil Hubert teaches young would-be technicians to understand culture, context, and behaviour first before attempting to develop their ‘hard’ skills.
So, about this ‘introduction to tech support’ that I’ve been teaching to young high school and university age kids … When I’ve brought the course up in conversation, the most common question that I’ve been asked (so far) is ‘why are you teaching all this abstract organisational theory instead of hard technical facts?’ I understand the question, and I’m not surprised that IT people would insist that ‘hard skills’ are the only skills worth imparting. That’s a common approach to ‘professional development’ in the IT sector. It’s also one of the primary reasons why we keep failing to grow our own leaders in IT: we assume that the engineering is difficult, and that anyone can learn leadership without deliberate effort. As if ‘leadership’ was little more than writing schedules.
The U.S. military had the same narrow mind-set back when we first designed our version of the office-level troubleshooter course. At one point, our central doctrine office published an official course curriculum that all us IT units were required to teach. We did … and it turned out to be a disaster. The week-long program was dedicated to teaching trivia (like ‘how many pins are on a particular style of RAM stick?’) and hands-on skills (like ‘how do you seat a RAM stick in a desktop PC?). We taught the service’s standard program for a year before the doctrine office reclassified it as ‘optional,’ then dropped it and designed our own. We got sick of ‘accrediting’ people who knew tons of useless facts but couldn’t actually help their cubicle mates.
In a similar manner, the military decided a few years back that all tech support people needed to be commercially certified in order to be considered qualified to do their job. For most techs, this meant weeks of dull memorization followed by sitting the CompTIA A+ or Security+ exams. After months of gruelling preparation and hundreds of dollars per head in test fees, we still didn’t have ‘qualified’ IT people … just inexperienced kids who could rattle off obscure TCP port IDs as if that somehow had anything to do with diagnosing networked device issues.
Obscure technical knowledge is only useful in pub quizzes and certification exams. Most tech support issues are solved via common sense and basic troubleshooting.
That’s why we largely pushed the hard-skills elements to the side in our home-grown course and focused more on context. The first quarter of our troubleshooter course focused on understanding the operational environment: what is the IT department? How is IT organised to support your mission? How does IT intake, triage, and track repair jobs? How do you get what you want out of IT, especially when IT’s staff is overloaded? By teaching the why elements before the how elements, our students understood how to optimize their role in the larger virtual IT organisation. Once returned to the field, they became … helpful. Useful. Credible, even.
Yes, we still taught some traditional ‘hard’ PC diagnostic skills, but we ignored all of the material that wasn’t ever going to get used. Our troubleshooters, for example, were forbidden to open PC cases or muck about with internal components. Therefore, why waste precious time teaching them how to swap out RAM? We chose instead to focus on the activities and concepts that the troubleshooters would use every day, like fault isolation, incident escalation, problem documentation, and courtesy.
One of those common practical skills involved understanding why users – especially managers! – tended to hate the IT department in general and were so often rude to the people assigned there. Also, in turn, why the people in IT acted angry all the time, as if they despised the users. The usual dysfunctional relationship between the customers and support service doesn’t seem to make a lot of sense; after all, IT only exists to make the business successful. In reality, most organisations have a bidirectional crap relationship that makes every interaction between the users and the support staff a monumental pain. We spent about an hour of class time exploring how that came about.
To begin with, the strained relationship has nothing to do with engineering trivia and everything to do with simple human dynamics. Interpersonal exchanges naturally create resentment between the two groups because of skewed exposure. It’s a context issue; the sort explained by industrial anthropologists, not engineers. Or, if you prefer, by cops.
Ever wondered why cops seem to be perpetually angry?
That’s right: cops. Consider your local Police Constable. Think about who that PC tends to interact with. There’s not a lot of engagement when a cop walks a beat. People tend to get nervous around someone that can ruin their life on a whim. Even saints try to avoid catching a cop’s attention. That’s why most people glide by a cop, giving him or her a wide berth, and avoid even basic human pleasantries so that the PC isn’t inspired to stop and chat … and, thereby, discover a reason to exercise his or her authority. It’s the same instinct that inspires a student to carefully avoid catching the principal’s eye: don’t trigger an encounter that might result in drama.
So, who does a cop mostly interact with during the course of the day? The ‘baddies,’ obviously. Not genius murderers (as television suggests); more like petty thugs, sullen malcontents, confrontational drunks, and other anti-social folks. People that are already upset, and so react belligerently to the PC from doing her job. People that are hostile and uncooperative. Stands to reason.
Imagine, then, working life from the cop’s point of view: during an average day, they pass a thousand perfectly pleasant and law-abiding people without having any meaningful interaction. Those non-interactions don’t factor into the cop’s impression of humanity. Instead, almost all of the people that the cop directly engages with are criminals (suspected or otherwise); people that don’t actually reflect society as a whole, but who leave a strong and negative impression.
Over time, this skewed view of humanity causes a perfectly normal cop to view everyone (who isn’t another cop) as a skeevy, nasty, dirt bag. In their direct experience, everyone has done something wrong or has something to hide. They begin to automatically suspect everyone of being like their worst encounters. That leads to aggression, defensiveness, cynicism, and finally to hostility … which, in turn, triggers negative reactions in the people that that they interact with. [1]
Makes sense, right? The more that anyone interacts professionally with people who dislike them and make them angry, the more that they’ll project those experiences onto the next person or group that they interact with. People make assumptions about future encounters based on past experiences. That’s true for coppers … and it’s true for tech support/user interactions, too.
‘I’m setting a one-time password for your account. You’ll need to change it as soon as you log on. You’ll need to use capital and lower-case letters, numbers, and this list of approved special characters …’
Consider the following hypothetical white-collar office: Angie the Service Desk Technician supports a population of 100 clerical types. Perhaps 20% of those users have advanced technology skills, 20% have abysmal technology skills, and the rest are considered functionally proficient (that’s a generous distribution for a non-IT company). You’d expect that one of every five people that call the Service Desk would be an advanced user who is calm, collected, and very easy to get along with. A great customer to balance out the next caller who doesn’t know his mouse from his moustache.
Realistically, though, that’s not what happens: instead, the advanced users rarely ever call in to the Service Desk. These people troubleshoot their own issues; they only ever call for assistance when things have gone seriously awry or when they need someone possessing administrative system credentials. By the time that the advanced users give up and call for help, they’ve gotten pretty frustrated … and that frustration leaks through in their tone, facial expression, etc.
Same thing goes for the functional-level users. They tend to avoid calling the Service Desk if they can help it. It’s easier for most of them to ask the advanced users in their office for direct help and, thereby, sort out their own problems. When they have to call in, it’s because they’ve hit a roadblock that their advanced user friends can’t fix … so they’re pretty steamed. Notice a trend? Most people don’t call the Service Desk when things are going fine. They call after they’ve become exasperated.
Meanwhile, the low-skilled users tend go about things entirely differently. They don’t learn how to use their equipment properly; if they were willing to do that in the first place, they’d be proficient users (QED). They don’t ask for help from the advanced users; if they did, and if they learned from the experience, they’d become proficient users (see previous parenthetical). The people that start off unskilled and thereafter deliberately remain unskilled are a unique category because they either can’t or else don’t want to learn. [2] Technology angers and frustrates these people … and they’re forced to use it, making every day a bitter chore. Whenever they hit a snag (which is often, since they repeat bad habits and don’t learn from mistakes), they have no choice but to call the Service Desk.
These, then, are the people most likely to interact with Service Desk: angry skilled users who resent being stuck, and frustrated un-skilled users who slow the entire organisation down like barnacles accumulating on a ship’s hull. Day in and day out: a steady flow of these frustrated people engages the Service Desk staff … and most of them start off with a bad attitude. Remember: no one calls the Service Desk to say ‘Hi! My gear works fine. Have a nice day!’
‘I JUST CALLED TO SAY GREAT JOB! THANKS FOR ALL OF YOUR HARD WORK!’
It’s a high probability, then, that when a Service Desk Tech picks up the phone, the user on the other end is going to be at least grumpy and possibly spoiling for fight. Imagine how that experience warps the tech support workers’ outlook toward their customers: a little Pavlovian conditioning warps their attitudes. The IT staffers begin to associate the ringing of the tech support line with hostility and abuse. They internalize their most memorable negative experiences as being typical of all user interactions. They grow defensive, then cynical, and finally starts to become bitter. The IT worker’s bad attitude, then, becomes evident at the beginning of a call and affects their customers, promoting a vicious cycle of nastiness.
As an embarrassing example, I had a Service Desk tech once completely lose his temper after dealing with a chronic complainer for the tenth time in one week. The user refused to take direction and kept making preventable errors, then blamed their equipment rather than their own mistakes. At the end of the last encounter, the Service Desk tech summarized the entire call in the trouble ticketing system with the diagnosis ‘User is a retard.’
Setting aside that the man’s choice of insult was unprofessional, EO complaint cringe-worthy, and un-helpful, the real damage came when the user received an automatic ‘issue closure notice’ from the trouble-ticketing application … that included the tech’s pithy diagnosis. Drama happened. In the short term, the tech had to be removed from the Service Desk to a non-customer-facing position. Over the long term, the story of what happened circulated through the entire campus, increasing hostility towards the Service Desk from dozens of users … including many in upper management.
As you’d expect, the increase in hostility from the users provoked corresponding hostility from the tech support workers, which triggered more hard feelings in the user community, and so on. It took years to recover from that one tech’s gaffe because of the simmering discontent that each side of the relationship held for each other.
‘Thank you for calling the Service Desk. Please vent your spleen about how all IT department employees are filthy animals now so that we can better serve you once you run out of invective.’
That’s why we teach organisational behaviour. The odds are darned good that any company that our ‘troubleshooter course’ graduates wind up in will feature a similar cultural conflict that makes tech support unnecessarily difficult. It doesn’t matter to the angry user whether or not the tech knows how many pins a DDR4 SDRAM SO-DIMM module has. [3] What matters is that they have a helpful, patient, and resilient attitude. A troubleshooter – like most Tier One tech support personnel – is the human liaison between the user and the IT department. Therefore, in their role as ambassador, they have to de-escalate tensions, build healthy relationships, and help mitigate past conflicts. It’s less about fixing specific PC problems and more about fixing personal and organisational dynamics.
Will this really help a young worker break into the IT sector? I say yes. After we removed the previously-mentioned snarky Service Desk tech from his position, we interviewed fourteen candidates to fill his empty billet. The one we hired had zero technical experience. What she had that made all the difference was an exceptional understanding of customer service. She explained in the interview how most of a service call involved letting an angry customer safely and non-judgementally expend their frustration first before any meaningful corrective action could be suggested. She was right … which is why she got the job.
All technical skill can be taught. Most general academic training needs to be re-taught anyway after the new tech starts because every organisation has its own unique internal processes and procedures. Therefore, an entry-level hire is better served with general technical education and a solid grounding in interpersonal business skills. These aren’t veteran escalation engineers, after all. We don’t need them to slot directly in to a senior engineering billet and start fixing problems immediately. They’re brand new to the field. We can teach them … so long as they don’t burn out from frustration first.
[1] This isn’t something that I gathered strictly from observation; I’ve spent decades hanging out with both civilian and military cops. Many described how their view of the world warped by spending so much time around jerks. Some admitted that they’d treated friends and loved ones like criminals, just out of habit.
[2] This isn’t meant to be a value judgment. I don’t have any interest in learning how to breakdance. My boss has no interest in learning how to become a Dungeon Master. To each his or her own.
[3] 260, as it turns out. I had to Google it.
Title Allusion: Henning Mankell, One Step Behind (1997 book); Henning Mankell and Richard Cottan, Wallander (Season 1, Episode 3: One Step Behind) (2008 television show).
Photographs under licence from Thinkstockphotos.co.uk copyright: headset, Andy Dean; burning laptop, kevron2001; cops, IPGGutenbergUKLtd; speeding ticket, IPGGutenbergUKLtd; I release you by phone, maselkoo99; call centre operator, belchonock
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.
