You can’t function effectively in a culture if you don’t understand the culture. Business Reporter’s resident U.S. ‘blogger Keil Hubert is training at-risk youth to work in IT, and finds that he’s spending more time teaching culture than engineering.
A corporate head-hunter hit me up last week with an absolutely smashing job opportunity: a long-term contract for a first-tier tech support agent gig making £20/hour. I don’t mean that it was a perfect fit for me, personally; rather, it was perfect for my students. Young men eager to break into the IT sector. Absolutely perfect. If only I could finish getting them qualified for the gig in time …
I’m positive that the graduates from my IT Troubleshooter course will be able to ace the interview and excel in the job once they’ve had a little seasoning from a senior tech. Unfortunately, the biggest impediment to their success right now isn’t their lack of skills or experience; it’s me. Specifically, because I’ve been too bloody slow in delivering their coursework. AAARGH!
It’s entirely my fault. I know that. Back when I first drafted the curriculum and training requirements for the original course, I was able to leave out a bunch of business and operational material because my military students worked in a severely limited information infrastructure. Our hardware was limited to whatever vendors and models Headquarters chose for us. We only had one Active Directory network to worry about, and we didn’t control it. We didn’t get to ignore orders from on-high. Many of the concepts and practices that a corporate Tier One worker has to know about simply didn’t exist in ‘our’ world. That meant that we could skip or compress a great many required teaching points. Now, using the old course for inspiration, I’ve discovered that many of our old training blocks don’t translate well to a non-government context. Lots of re-writing is required.
Just like a Medieval monk hand-copying a manuscript, most of my course edits start with extensive marginalia before I finally give up in exasperation and re-write everything.
This really bit me when I tried to convert one of the larger modules: PC Architecture and Operating Systems. The first time we taught it, we’d managed to keep the module down to 20 slides and an 8-page student workbook. We gave the instructor the longest time slot of the day – 90 minutes! – to teach it. At the time, it seemed to work: the block was an orientation with no practical exercises. Just the basics: what is RAM? What kind of removable media drives will you encounter? Why does a PC need an operating system? That, and a bit of basic error management training and we were done.
I think the module was fine … in its original context. As far as my new IT Troubleshooter course is concerned, the core learning objectives were in-line with what the students needed to know. Sure, the eight-year-old content needed modernizing, but that shouldn’t have been too hard. After all, the qualifications required for a first-tier tech support agent gig are pretty easy to meet. The one that I received last week read (and this is an exact quote):
- Student or University Graduate (Technical University Degree is an advantage).
- Two years of related work experience, or an equivalent combination of education and experience.
- Experience in the use of remote IT support tools.
- Has worked with, and can troubleshoot, Microsoft desktop products.
- Good knowledge of Microsoft Operating Systems local and remote administration.
- Good knowledge of the Microsoft Office family applications (especially Outlook).
- Basic hardware troubleshooting [skills].
- Basic software support [skills].
- Very good communication skills.
- Exceptional phone etiquette.
- Excellent customer service skills.
- Flexibility and ability to work shifts.
Not that hard to qualify for, really, especially when you consider that most employers over-state their requirements in the hope of landing a dream candidate, and will often hire someone that has most of what they need so long as he or she has a good attitude and a strong work ethic.
The ability to gracefully accept constructive criticism is a definite plus.
I figured that our new version of the PC Architecture and Operating Systems block ought to satisfy requirements 4 and 8; all I needed to do was modernize the content. Just replace Windows Vista with Windows 10 and drive on, right? Shouldn’t take more than a cursory pass through the lesson plan, slides, workbook, and handouts and we’d be ready to go, yeah? Yeah, no. Not so much.
The more that I tried to update the old content, the more mangled the new version became. I discovered that there was so much background and context missing from the originals that my students would have been bitterly underprepared for a modern IT gig. I wound up scrapping several attempts at simple edits and re-wrote the modules from scratch. By the time I was done, I realized that I’d created a monster: 20 slides became 55. An 8-page handout grew to 30 pages. The lecture … Oooh, that hurt! It grew from 90 minutes to four bloody hours long. Worst of all, it took me nearly three weeks to get the documents polished enough to present since I was only able to devote time to the project during workday evenings.
I wound up splitting the content into two related (and more manageable) presentations: one called PC Hardware Support and a logical companion called PC Operating System Support. I culled the fine details about how many PINs an SO-DIMM has because who really cares? I replaced the technical trivia with a little bit of necessary historical context, like where did PCs come from? How did they evolve in the business world? And how has tech support changed over the last decade? None of that practical information existed in the original build. Looking back on it now, I think that we made a mistake by skipping the critical cultural, contextual, and historical elements of IT support.
You might ask why that matters. Who cares how the shift from minicomputers in the 1960s and 70s to standalone PCs in the 1980s changed business processes and expectations? What does that have to do with fixing PCs today? Well … it has a lot more influence on how support is performed now than you’d expect. Take, for example, last week’s ‘WannaCry’ malware outbreak.
Also known in InfoSec circles as the ‘THIS IS WHY YOU HAVE TO PATCH!’ outbreak.
When TheRegister’s Iain Thomson summed up the current state of the crisis on Saturday, 13th May [1] he included this synopsis about halfway down the article:
‘We’re told 16 NHS health trusts in the UK were taken out by the malware. Prime Minister Theresa May said the code “has crippled” Brit hospitals, and that Blighty’s surveillance nerve center GCHQ is looking into the outbreak. The NHS is thought to have been particularly hard hit because of the antiquated nature of its IT infrastructure. A large part of the organization’s systems are still using Windows XP, which is no longer supported by Microsoft, and Health Secretary Jeremy Hunt cancelled a pricey support package in 2015 as a cost-saving measure.’
There’s a ton of important information to unpack in that paragraph. For my students’ sake, we discussed how the NHS got infected in the first place (probably via phishing), how the WannaCry ransomware affected NHS hospital operations (denying users access to clinical documents stored on PCs), how the worm component spread the malware inside the organisation (laterally, via SMB scanning), why the NHS’s IT department didn’t just ‘burn’ the locked PCs and reload spares from backups (presumably, lack of Business Continuity Plan resourcing), any why on God’s green earth were bloody Windows X-freaking-P machines still running in the organisation (procurement delays, bespoke and third-party application lock-ins, embedded PCs running clinical equipment, etc.).
Understanding the answers to these crucial questions requires a nuanced understanding of how organisations purchase, deploy, and support their IT equipment. You have to teach concepts like ‘lifecycle management,’ for example, where equipment is deliberately replaced and retired before it’s out of warranty. How the LM process gets short-circuited by budgetary limitations, so that obsolete equipment remains in operation past the point where it can be properly supported or secured. Concepts like management’s risk appetite, where senior leaders take responsibility for leaving equipment unpatched because they can’t afford to implement proper security configurations, or because updates might render the item degraded or inoperable. Troubleshooters need to understand how business considerations unfailingly undermine what seem like inarguable technical requirements.
You can argue facts and logic until you pass out; it rarely matters. Many IT decisions get made by people who don’t know – and don’t care to learn – anything about IT.
These are all subjects that an ‘old hand’ in the IT world understands. A major part of doing one’s time ‘in the trenches’ (so to speak) involves discovering the age-old battle between what should be done according to IT governance best-practices and what IT is allowed to do according to the senior businesspeople. Every IT worker goes through this shocking disillusionment process: a tech goes to perform a critical task, a businessperson halts the work, the tech gets (quite rightfully) angry because the work needs to be done, and the Head of IT takes the new tech for a quiet walk around the building to explain how and why things really get done in the organization. This conversation is a crucial rite of passage for IT workers. Coming to grips with the pragmatic side of the job is an essential part of the transition from being a greenhorn junior tech to becoming a seasoned senior tech.
Most people develop some basic tech skills in school, at home as a hobbyist, or else on the side while working another type of job. When they join their first IT team and try to apply their black-and-white technical knowledge in a complex, nuanced political environment, they discover that being technically right doesn’t carry nearly as much weight as holding the authority to insist on doing what’s right. Roughly one-in-three new IT workers can’t handle the revelation and either quit or get themselves fired; temperament, not skill, determines whether or not they ‘make it’ in the IT sector.
Another one-third of new techs find a way to accept the ‘injustice’ of it, but resent the business side’s interference in technical operations … pretty much forever. They never evolve past the ‘individual contributor’ performance level. These are the hard-core engineers who give us the pop culture trope of IT people as being sullen, waspish, and bitter. People who know how things should be done, and hate the world because the incontrovertible truth often gets ignored by fools.
The remaining one-third are those people who strive to understand the self-defeating environment and learn how to deal with it on its own terms. These are the people who grow up to be effective IT managers, directors, and executives. They’re the people who learn how, when, and why to balance business needs with harsh technological realities. They fight back when it’s necessary, and wisely refuse to squander their political capital on trivial conflicts. They’re the savvy folks who craft long-term strategies to mitigate the threats posed by poor decision-making and political compromises. They’re the sort of IT workers that competent senior leaders are desperate to hire and to retain.
Those people that you can absolutely count on to have your back when everything goes to hell.
That’s why I’m trying to teach these concepts to aspiring first-time IT sector workers. I want these young people to have a fighting chance to break out of their minimum-wage unskilled McJobs track [2] and get into something better. Something that will actually provide them a living wage, decent working conditions, and maybe a fair shot at career progression. A chance to survive in an adult world that seems cold, alien, and hostile to everything they’ve been led to expect. [2]
In order to achieve that goal (I realized), I need to teach my students the language, culture, and history of the strange new land they’ll be working in. They have to understand how we all got to this loony place before starting work. They need to be inoculated, so that they don’t make a complete fool out of themselves arguing (perfectly logically) that an IT decision is barking mad. They need to understand how politics, finance, and poor decision making have more impact on technical architecture and operations than standards, practices, or governance models ever will. This is the state of the IT world, and it needs to be understood. Moreover, the usual dramatic eruption that every new tech experiences needs to be pre-emptively disarmed, like unexploded ordnance.
That’s the critical strategic advantages that I want my students to gain from my course: they’re not a drama bomb waiting to make their boss’s life miserable. I want my students to possess a nuanced and dispassionate understanding of their new work environment. If I do my part right, my graduates should be able to take a first-tier tech support job and function effectively in it with zero drama. There won’t be any need for them to take the traditional quiet walk around the building with the Head of IT to have how things really get done explained to them because they’ll already have that sorted. All they’ll need is some supplemental technical instruction and they’ll be good-to-go.
In my twenty-five years of leading IT teams, I’ve found that this is one of the most important lessons that a tech can learn. It’s what separates effective techs from talented-but-ineffective ones. If I can teach this concept correctly, it’ll come through in the interview and set my graduates apart from their competition as a superior choice: a tech who’s ready to work without the normal threat of a drama bomb waiting to go off. That’s a worker worth investing in.
[1] The complete article title was ‘74 countries hit by NSA-powered WannaCrypt ransomware backdoor: Emergency fixes emitted by Microsoft for WinXP+’. Banks’ article, by the way, is an excellent example of how to explain complex information security topics to non-technical readers.
[2] The literary inspiration for this column comes from Michael Crichton’s 1976 novel Eaters of the Dead. The story is written as the diary of a 10th Century Muslim Arab who travels North to Viking lands. The core theme of the protagonist’s character arc is that he’s an outsider in a strange land. In order to understand what’s happening around him, he has to learn his host’s language, culture, and history. Once he grasps the context, he’s able to participate in the main plot. After an hour of experimenting with word substitutions, I accepted that neither the book title nor the movie title translated coherently into an article title, so I chose an appropriate quote from the text instead.
Title Allusion: Michael Crichton, Eaters of the Dead: The Manuscript of Ibn Fadlan Relating His Experiences with the Northmen in AD 922 (1976 book); Michael Crichton, William Wisher Jr., and Warren Lewis, The 13th Warrior (1999 film).
Images under licence from thinkstockphotos.co.uk, copyright: viking ship, MR1805; buddhist monk, Studio-Annika; hammer blows, Mladen_Kostic; megaphone, LightFieldStudios; sleeping, Bavorndej; viking woman, SergeyKlopotov
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.
