Qualifying young people for entry-level IT jobs is tougher than you’d expect. Business Reporter’s resident U.S. ‘blogger Keil Hubert argues that most vendors do a poor job of it, because they try to teach engineering trivia instead of practical customer service skills.
A frustrated scholar once complained to me that the technical support I was delivering wasn’t at all helpful because ‘everything on the screen was moving too quickly.’ I tried my best to slow things down, but it didn’t help. The client wasn’t grasping what I was trying to explain. That made us both stressed and frustrated. Eventually, the scholar enlightened me with an off-hand comment: ‘Ninety percent of learning a new skill involves knowing where to look.’ He then showed me how the sheer cacophony of items and menus on his screen made it hard for him to see what I was actually doing.
He was (and still is) entirely right. We all tend to think that understanding how to use computers, phones, and tablets requires deep education on the fundamental components of each system. That’s why every CompTIA class that I’ve purchased for my tech staff spent the majority of its time focused on presenting engineering trivia. That is, memorizing technical definitions that anyone could (and would!) look up on Google when-and-if needed. Unfortunately, none of that esoteric trivia ever helped a student (or a user supported the student) understand how to use their equipment properly.
I kept that lesson firmly in mind when I started overhauling the content for what would eventually become my IT Troubleshooter course. My intent was to get young workers ready to take on entry-level jobs in the IT sector after graduation. To make them attractive to a potential hiring manager as someone who has the right context, mind-set, and people skills to function effectively in a corporate IT setting, and the demonstrated ability to learn new technical skills as-needed. With raw material like that, any decent IT manager should be highly interested in snapping up my graduates.
To that end, I attempted to shift the focus of the content off of brute-force memorization (as it had been in the original build) and over to more context- and function-oriented discussions. I dropped all of the trivial technical details out of the Operating Systems Architecture block, for example, and changed its focus entirely to OS support. As in, what’s likely to go wrong, how do you recognize it (where do you look!), and how can you then set things right. With the change in focus, we managed to cover a lot more OSs than the original course had; I added DOS, macOS, Red Hat LINUX, and z/OS [1] to the original’s parade of Windows versions, but for recognition, not definition. [2]
‘Based on the primitive user interface, the slow response time, and its inability to run without blue-screening for more than five minutes, I believe that we’re looking at Windows ME. Therefore, the optimal repair action is to take the machine out to the car park and light it on fire.’
The intent of the new block wasn’t to generate obscure test questions; it was to show students how the *£&$ we got to where we are now, why that matters, and how it affects the job. 1980s computing looked like this (with appropriate examples) and required these skills at the time. 1990s computing changed with the GUI and networking to look like this (comparing and contrasting examples), which in turn changed how IT support was performed like this, etc. Why do we have a centralised Service Desk? Why are infrastructure and operations teams treated like starkly different tribes? Why is the desktop PC often considered the focus of IT’s organisational structure instead of the information itself – or the data centre? Understanding the history behind evolutionary changes makes seemingly-bizarre professional behaviour start to make sense. Some sense, anyway.
This is where that ‘knowing where to look’ principle becomes crucial to developing a student’s skills. By the end of the OS block, my troubleshooters had a solid grasp on how to determine which PC OS they were dealing with by looking for essential visual indicators in its user interface. That’s a useful ability; by figuring out what kind of system they were being asked to fix, they’d know whether or not they were qualified and/or authorized to work on the troubled system. If the misbehaving box was out of their individual scope of practice, they’d know where in the IT department to route the incident ticket to based on how the IT operation was organisationally structured. [3]
I applied the same principle to the Applications Support block. We covered the most common applications and tools that normal users were likely to have installed on their PCs, starting with the Microsoft Office apps. It wasn’t meant to be an endorsement of the Office product so much as a statement of fact. Yes, there are some companies out there using competing products like Open Office or iWork instead of Microsoft’s products, but those companies are bravely bucking a global trend. Microsoft dominates the desktop applications space. Accept it and move on.
The Office introduction started with what is and what isn’t bundled in each version. A minimalist PC will likely have Word, Excel, PowerPoint, and Outlook installed on it. The ‘where to look’ principle in this block involves understanding the company’s software standards. What specific Office products does the company deploy to every PC? What options are there for adding on additional apps under existing license agreements? More importantly, how should a user submit a request for a new tool? This isn’t technical; it’s entirely organisational. It’s also a crucial support function.
One of the best things you can do is to standardise and document these processes. You’ll bank user goodwill by taking all the drama out of the process.
This required an orientation to the different builds of Office and the OS-restricted apps problem. I discussed how our Service Desk used to get at least one support call per week from angry users who thought that they were ‘missing’ an application that they felt they were ‘supposed’ to have. Seriously: I took a call once [4] from a life-long Windows user demanded to know why Microsoft Access wasn’t loaded on her MacBook. She couldn’t grok the fact that Microsoft Access is a Windows-only application. Similarly, I used to get angry calls from users who had come from other companies where apps like Microsoft Visio or Microsoft Project had been installed by default on every company PC. They didn’t like being told that our Enterprise Software Agreement didn’t cover those; if they wanted them, their department would have to pay for a new license. This is 100% normal Service Desk business … but it’s not the sort of things that most people encounter in non-work life.
Similarly, students who had never worked a corporate job before considered Outlook to be an odd duck. Most of my students grew up with web-based e-mail (Gmail, Yahoo! mail, etc.) and had either used a browser for their mail interface or else used the default mail app that shipped on their phone. It was difficult to explain the complexity of a do-everything corporate communications console to students who have only ever futzed about with basic e-mail. Adults who have lived the corporate IT experience stop questioning the dominance of Outlook; it’s just how things are. This makes e-mail (and calendar management, tasks, mail voting, mail reminders, et al) an easy place to get tripped up. Outlook does a lot more than mail, and it’s easy to get confused trying to us it.
That’s why I re-built all of the old military-oriented tech support content to explain IT life in a corporate context. Every one of our lessons ends with a discussion about what the students are likely to encounter in an operational environment. Which operating systems are they most likely to see deployed and why? Which applications are the users most often going to need help with? How will incident tickets get routed for diagnosis and repair within the IT department? Why does it take so long to get relatively easy issues resolved? Why don’t old, dirty, beat-up PCs get replaced before they’re completely obsolete? These are the questions that keep users perpetually frustrated.
‘Where to look’ in this case isn’t found in any technical manual; the place to look is on the IT department’s org chart, its funding plan, and the its work prioritisation protocols. Getting these principles across involves showing students how a typical IT Department is structured, staffed, funded, and led. All IT Departments have a finite capacity for support work; based on the number of people they have with key skills, they can successfully support only so many variations in what’s called ‘the PC fleet’ before they run out of time, parts, and expertise. This is why IT groups standardise on just a few PC models, OS builds, and common configurations.
Unlike the old-school approach of ‘If you buy it, IT has to support it no matter how weird it is’ (That historical anomaly didn’t end well).
Users are bound to ask for the tools that they need to do their jobs. Most of the time, users have preconceptions about what they need based on what they had available at a previous employer or department. When they ask for something that’s out of the ordinary (and they should!), it’s the field tech’s duty to work with the requester on behalf of the larger IT department. The first-level tech has to know (a) what ‘normal’ is for a company PC, (b) what variations (like non-standard applications) are authorized and ‘easy’ to add, and (c) what variations are likely going to be difficult to get (and how to ask for them).
It’s crucial to remember that most workers just want to do their jobs with a minimum of drama, collect their pay, and go home. They don’t want to invest hundreds of hours learning how the company’s IT machine works; they just want someone who has invested that much time to give them a straight answer in terms that they can understand. Hence, the crucial role of the first-tier Troubleshooter. For the user, the question of ‘where to look’ is a matter of personnel, not technology. The IT Troubleshooter is the answer; a good field tech is an advocate, ally, and knowledge base that users can tap as-needed to help get things done. In turn, a good field tech can neutralize anger and drama at its source by preemptively derailing misunderstandings.
None of these crucial functions get taught in a traditional IT skills class. They have to be learned the hard way: by making career-threatening mistakes on-the-job. That’s a darned shame, since it’s exactly these functions that build trust and respect between the IT worker and the beleaguered user community. If I can teach these concepts to young techs up-front, it ought to make them immensely valuable to a potential IT manager. That ‘boost’ should help get them ‘in the door’ with an IT group so that they can post a real tech-sector title on their CV. That, in turn, should help catapult them to decent-paying and fulfilling careers in the IT space.
That’s the plan, anyway. Fingers crossed that it works as-intended.
[1] IBM’s mainframe OS. Yes, mainframes are still a thing, and they deserve a little love for playing their part in the data centre.
[2] The original course only focused on three versions of Windows.
[3] For organisations that split up Windows and *NIX platforms (for example), all LINUX workstation jobs would get routed to the *NIX team so as to avoid wasting time in the default Windows support queue.
[4] I used to cover the Service Desk while my techs were away in training. It helped me stay oriented to the sort of inquiries we were getting and how users treated my staff. It also confounded the *£&$ out of the users, since they never knew if their support call was going to be answered by an 18-year-old apprentice tech or a mean old Director.
Title Allusion: None this week. I think I’m allowed to break my own rules when they’re (a) completely arbitrary, and (b) only employed for amusement’s sake.
Images under license from ThinkStockPhotos.co.uk, copyright: training session, BartekSzewczyk, salespeople, BartekSzewczyk, professor, Huntstock, computer parts, bdStudios
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 Reporter’s resident U.S. blogger.
