If you don’t have shared workplace experience to draw on when teaching, a shared pop culture experience will have to do. Business Reporter’s resident U.S. ‘blogger Keil Hubert describes a nautical analogy for teaching various IT department sizes and structures to would-be IT troubleshooters.
Metaphors and analogies are bloody difficult beasts, don’t let anyone tell you different. Coming up with new ones that succinctly and adequately convey a concept without mangling some aspect of it can be exasperating. Getting through to someone with external references requires that both the speaker and the receiver share the context that explains the allusion. Trying to synchronize ideas via analogy when the two parties have wildly different understandings of the notional references is likely to screw everything up. If you’re lucky, you’ll only waste your students’ time; if you’re cussed unlucky, you’ll all think that everything came though correctly, only to discover months later that you’d imparted the exact opposite of what you’d originally intended. Mayhem often ensues.
If you caught last week’s column, this week’s is a continuation of it, so skip ahead. If you missed last week’s, here’s the executive summary: I’ve been refurbishing an old ‘introduction to tech support’ course from my military days in order to train young high school and university age kids how to qualify for entry-level tech sector jobs. The idea is to arm young men and women with the ‘big picture’ information that they need to convince a hiring manager to take a chance on them: ideas like troubleshooting techniques, the relationship between the Service Desk and the user community, and so on. It’s primarily focused on the job environment knowledge that allows a corporate employee to slot into a new cubicle job without drama or trepidation. Managers value this more than raw ability.
Back on track: The refurbishment of my old tech support training course has been frustrating because I can’t rely on shared cultural experiences to get ideas across. Back when we originally designed it, we had military standardisation on our side: every student had been through the same Basic Training routine, had lived in the same organisational structure, had taken the same annual awareness courses, and so on. We could draw on a deep well of shared cultural touchpoints. This accelerated our ability to convey ideas, while keeping the audience comfortable. Yes, the tech stuff was daunting, but the students understood all of our references, so everything made sense to them.
Frame a new idea in terms that the students already understand and they’re far more likely to get your point (especially if they’re interested in the topic).
But for teaching civilians? Pfft! Nope! Somewhere around four-fifths of the old external references that I came across while editing the lesson plans, student handouts, and slide decks fell flat when presented to a 16-to-25-year-old who has never served a day in uniform in his or her life. So, in order to get the necessary point across, I’ve had to generate all-new pop culture references to replace the military environmentally-specific ones that we’d written for the original military-only version.
Case in point: the intent of the fourth training block is to explain the different structures and capabilities of IT departments, framed in the context of different company sizes, in such a way that the students can understand what sort of IT team they were dealing with (and where that team needs help!) when they sit their interviews. In the original, this was a simply an overview of the IT squadron’s organisational structure and the occupational specialties of the workers. Basic, dull, … and useless for civilians. Matching mental models mandated non-military metaphors.
I’d already crafted one functional analogy based on Navy movie references for this block (see last week), so I decided to stick with movie- and television-based (rather than reality-based) Navy analogies for the second half of the content. I needed to explain how the size of a commercial business affects the structure, organisation, and mind-set of their IT department. This, in turn, would affect how the IT department interacts with its customers – vital information for a would-be tech support agent. If they could grok that concept, it would give them a huge competitive advantage.
First, I broke the tiers of businesses [1] down into six b-school categories for convenience’s sake: sole proprietors, start-ups, small companies, medium companies, large companies, and enterprise operations. I dropped sole proprietors from the discussion because they don’t have an IT staff. I also consolidated large- and enterprise-level companies because their IT capability honestly isn’t that much different in structure; only in population. That left me with four categories to describe:
May as well jump straight into the subject
Start-Up Companies. These (I explained) are the fast-paced, loosely-organized, chaotic messes that us curmudgeons love to make fun of. Most start-ups that I’ve encountered haven’t had anything close to a formal IT shop. Instead, they have ‘that one tech guy.’ There are usually one or two people on the team that happen to know more about tech stuff than everyone else, so those guys do a little bit of tech support on the side. It’s all low-level work (like buying PCs, setting up a team printer, etc.), performed ad hoc, with no consideration of continuity, standardization, documentation, or quality. That fits perfectly with the common move-fast-or-die Dot Com ideal.
Using a warship analogy, a start-up’s IT ‘department’ isn’t a real warship at all; it’s little more than individual swimmers. That is, there’s no ship to speak of. Each tech support agent is self-directed, and only does support when they’re not committed to their ‘real’ job. That means they have limited capability, finite endurance, and very little attention to spare for anything other than time-sensitive emergencies. If you’re thinking in terms of sailing the seas, this doesn’t work; a swimmer can’t cross an ocean. Likewise, a couple of well-meaning volunteers can’t keep a data centre functioning. That’s okay, because they’re not trying to. The purpose of a start-up is to prove that its ideas are worthy of investment. Once the start-up gets funded, it grows into a small company and expands.
Small Companies. Once a company starts deliberately assigning specific full-time roles to people, it evolves into a legit small business. Functions may be outsourced, but core roles are usually staffed with trained and qualified employees. This is where a new junior support tech can really make a name for his- or herself: being enthusiastic, helpful, and competent when you’re a big fish in a small pond banks gratitude and loyalty; this will help keeps you around when your company evolves.
The thing about small companies is that their IT ‘department’ is usually small – quite small. Each employee may have a specialty, but everyone on the team helps out as-needed. More importantly, because the team is so small and the conditions are so intimate, everyone in IT knows everyone else. They achieve a level of mutual respect and work things out informally. Using the warship analogy, they’re more of a canoe (or rowboat, if you prefer). As long as everyone cooperates, the team is capable of staying afloat indefinitely. They can even make decent progress as long as their goals are modest and they stay close to the metaphorical shore. They may lack the capability to play in the deep depths, but they’re fully able to surge to meet the business’s (relatively simple) needs.
There’s operations in the front, infrastructure in the back, and management providing no meaningful help whatsoever in between. Perfect visual metaphor
Medium Companies. This is (I argue) what people imagine when they consider what an IT ‘department’ must look like: something formally structured, divided into functional branches or teams, led from the top by a dedicated leader, capable of 24/7 operations, and staffed with seasoned professionals. At least, that’s how it supposed to be; many IT departments don’t quite measure up. That’s okay; in this size tier, IT is just one critical utility among several that keep the business healthy. As long as the business’s needs are met, then its IT support function works.
This too is a great place to pick up an entry-level IT job, because there are so many interesting (and lucrative) specializations to move into once you’ve proven your tech chops. More importantly, there’s room for trainees in a medium-sized IT shop. These organisations are accustomed to signing and training junior employees as a hedge against future losses. The downside to them is that they’re so large that it’s often difficult (if not impossible) for any given IT worker to know all of his or her teammates – let along all of their customers. This causes compartmentalisation to set in, creating rivalries. It also makes it difficult for anyone to stay on top of the total operational picture.
Still using our warship analogy, a medium-sized company’s formal IT department is like a destroyer: self-contained, fully-operational, fast, and robust. It has formal leadership at the top, and each major division has its own qualified functional leaders who keep the teams running smoothly so that the top manager can focus on strategic, long-term concerns. This is the first IT department that we’ve looked at that’s considered fully operational according to the optimal structural models. Just like a modern warship can go anywhere it darned well wants to and can stay there for as long as it has fuel, a medium-sized company’s IT department is capable of sustaining its primary functions indefinitely, and can evolve itself with new technology as long as the company remains sufficiently profitable.
In another parallel, the biggest danger to both a warship and an IT department is a dangerously incompetent senior leader
Large Companies. Finally, there’s the top of the heap: the FORTUNE 500 businesses. Multi-site or even multinational enterprises that employ thousands or even tens of thousands of workers. These IT teams are essentially medium-sized company IT departments in and of themselves. They’ve been scaled up and expanded as the company evolved in order to cover obscure new functions that only a behemoth needs to address. This includes roles like formal governance, auditing, quality control, multi-lingual services, formal accreditation, and much more. The same operations, infrastructure, logistics, and security functions are all there, only much, much larger since each core function is resident in parallel across multiple geographic locations.
In a large company’s IT function, strategic leadership is mandatory – and there are often multiple executives all supporting IT (e.g., a CIO, CTO, and a CISO). Leadership runs across national lines, product lines, and service support lines making everything complex and cumbersome. As a result, there are usually hundreds of initiatives going on at once. Duplicate projects are rampant, and often become difficult to stamp out. Internecine conflicts are more common than successes. It becomes difficult for the organisation to change direction swiftly given the conflicting layers of authority. Finally, the whole operation is darned expensive to maintain. Still, these IT jobs can be prestigious.
In our warship analogy, a medium-sized company’s formal IT department isn’t like a single ship – it’s a bloody battleship flotilla. That is to say, it’s like many different types of capital vessels all trying to coordinate their activities towards a common objective, while each vessel is run by a different captain who holds a completely different perspective on How Things Are Done. These flotillas can be tremendously powerful, but are sometimes too big to get out of their own way.
Flotillas also suffer from the same inherent vulnerability that bedevils international companies: chief executives forget that their subordinate senior leaders are operating with a fragmentary and skewed operational picture
So, we have a working analogy. It’s a bit daft, but it gets the point across. So why does it matter? After all, PC repair is PC repair no matter how large the organisation is that owns the PC. Well … remember the original ship-versus-sub analogy: In a perfect world, the Service Desk technician receiving a new issue report would route the job to the technician at the next higher support tier that has the training, tools, and authority to resolve the issue. In the real world, however, jobs often get misdirected to the wrong team – to someone that either doesn’t understand or can’t fix the issue.
Why? Put simply, function follows form every bit as often as the reverse. People – and organisations – view their world through the lens of their own capabilities and limitations. If a group doesn’t have the exact right solution to an issue, they’ll usually try in good faith to attack the issue with whatever process or technique comes closest to what they think the issue resembles based on what they’re capable of doing. Often, this means turning the next phase of the issue investigation over to someone ill-equipped to address it. This isn’t incompetence so much as a failure of imagination. An inside-plant cable maintenance team will investigate the integrity of the affected system’s network cabling … which won’t do anything to help correct a software configuration error. But since ‘cable dogs’ generally don’t ‘do’ software, the assigned infrastructure tech is neither equipped nor trained to address the real issue.
This means that a trouble ticket will usually bounce around between several different teams, each of which will likely have a completely different troubleshooting method. A great deal of time will get wasted (in good faith) while various engineers try to troubleshoot the issue ‘their way’ in order to try and isolate its probable cause. The resulting outcome is predictable: once one group rules out that their piece of the puzzle isn’t the one screwing up the affected device, the trouble-ticket then gets routed to the next-most-likely group who try again – often from square one. Sometimes, the frustrated techs don’t read the ticket history and kick the job back to a team that’s already ruled out their own domain. This is why a relatively simple repair job can take weeks to resolve. Or never get resolved at all.
After a few such pointless encounters with IT, some business units completely give up and take IT support into the own hands … Often with disastrous results for cyber security.
This is why understanding the size and structure of one’s IT department makes a huge practical difference for a troubleshooter. When the first-responding tech knows how a ticket is likely to be routed for fault determination and resolution, she can shrewdly perform the common diagnostic processes that Tier Two will ask for in order help to rule out potential dead-ends. That way, once the issue gets kicked up to the Service Desk for resolution, many of the unproductive escalation options will have already been eliminated, and the valueless rabbit-paths closed off … thereby significantly increasing the likelihood that the ticket will get routed where it can actually be resolved.
Admittedly, the swimmer-canoe-destroyer-flotilla analogy isn’t perfect. It does, however, rapidly and accurately get across the core ideas surrounding unit cohesion, unit size, depth of capability, susceptibility to personal politics, manoeuvrability, scope, and probably internal difficulties. Does this qualify a person to fix broken PCs? No. It does, however, demonstrate to an overworked hiring manager that the applicant understands what they’re going through. That alone, sometimes, is enough reason to bring a new recruit aboard. Technical skills are easy to teach. Political skills … well, politics usually have more of impact on an IT department’s survival than technical skills do. Some workers never understand that … which makes those gormless engineers more of a liability than an asset to the IT department.
[1] I only wanted to discuss non-IT businesses; most dot-coms aren’t interested in hiring a kid with no experience for a tech support role. They’d rather hire a fully-qualified worker and pay them as if they were a kid with no experience.
Title Allusion: C.S. Forester and Edmund North, Sink the Bismarck! (1959 Book and 1960 Film)
Images under licence from thinkstockphotos.co.uk copyright: military kayak, zabelin; inventive kids, Zinkevych; learning to swim, Sirichai Chitvises; military ship, MihailDechev; flotilla, Stocktrek Images; welding, PJ66431470
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.
