People aren’t born knowing how to be effective IT managers. Business Technology’s resident US blogger Keil Hubert reaches back to the early 1980s for an ‘IT management simulator’ game that does a darned good job of teaching people how to pragmatically approach the job.
How do you train new people to become effective IT managers? It’s pretty easy to appoint someone into an IT leadership role: you can promote a good worker out of the ranks of individual contributors, or you can appoint one of your golfing buddies into the position as a sinecure (that’s how most outfits handle it). That’ll get you an IT manager, but not necessarily an effective one. To be decent at the job, a good IT lead needs to have a solid understanding of the many competing factors in play that threaten to overwhelm the team’s capabilities and sour the worker’s morale. They need to understand the principles of balance, expectations management, and acceptable effort.
One of the best IT management decision-making simulators that I’ve ever seen debuted nearly two years before Apple unveiled the first Macintosh. It wasn’t a digital product – it shipped in a cardboard box, and it was made out of paper and printed cardboard tokens. It also had William Shatner’s and Leonard Nimoy’s likenesses on the front of the box. For the 99.999 per cent of readers who weren’t gamers back in the Reagan-and-Thatcher days, I’m talking about FASA’s original Star Trek: The Role Playing Game, circa 1982. I bought this game from my neighbourhood bookstore when it first debuted. Yes, I still have my original set – and I hadn’t opened the box before this morning in… decades. Wow.
For perspective’s sake, the early eighties were a weird time when it came to game design. Arcade games were crude and not terribly immersive. Dozens of new pen-and-paper games were hitting the market, each trying to improve on Gary Gygax’s original Dungeons & Dragons rules that he and some mates first published in 1974. Rules and gameplay conventions were pretty much unique to each release back then, so knowledge of how to play one game didn’t necessarily translate into any ability to play another product. That free-for-all mentality let game designers mess around with all sort of interesting concepts, including different ways to simulate different parts of their game world.
Along those lines, FASA’s Star Trek game included a mini-game for simulating starship combat – a game within a game, so to speak. When the games master decided that the intrepid crew of a mighty Federation cruiser had (as per usual) come into conflict with a mysterious alien vessel, said games master would clear the table, rummage around in his game box, and pull out a bunch of blue ‘console simulators’ and cardboard markers. Each player fulfilled a key leadership role on the ship analogous to the roles played by the lead characters on the original sixties television series: the player serving as the ship’s helmsman got a sheet with marker scales for the propulsion and weapons. The ship’s communications officer got a tracker for casualty reports. Most important, the ship’s engineer received a double-sized sheet with markers for engine power production, and tracks for how much notional power he or she was making available to movement, shields, and weapons. The player occupying the captain’s chair didn’t get a console; she bossed the other players around.
What made the mini-game great (for me) was the novelty of having to make pragmatic decisions about how to balance the allocation of limited resources between offense, defence, and movement. The engineer started each game turn with only so many ‘points’ of power from the engines. Depending on what the ‘captain’ wanted to do (vis-à-vis the enemy vessel), I’d get to make a tough decision about what capability to temporarily emphasize and what to short. ‘Helm’ would then get to move our cardboard counter on the giant star field map, and might get to roll some dice, taking a shot at the enemy’s cardboard counter. The baddies’ ship might then take a shot at us – and if they hit us, my decision on shields power might save us, or cause us to take a bunch of notional casualties. Eventually, whichever ship made fewer mistakes during the battle won the day.
13 year-old me found this game endlessly fascinating, since there was never an absolutely right answer for how to satisfy all of the other players’ perceived needs. When crewing engineering, I only had enough power points to maximize the effectiveness of one of our three resource areas; we could run, or we could blast, or we could take a punch. Or we could try and divvy the points up evenly, making us a bit middling in capability all-round. Further, every time that we took a hit hard enough to breach our shields, our engines would take damage… thereby reducing their maximum available power output for all subsequent turns. The game’s rulebook actually spoke to quandary:
‘On many ships… it is possible to channel all power into shields. Doing so, however, leaves the ship unable to manoeuvre or fire weapons. Likewise, putting all power into weaponry leaves the ship stationary and vulnerable. Allocating power for maximum manoeuvrability leaves the ship without weapons or shields! Obviously, a compromise must be found, and the power allocation adjusted turn-by-turn as the needs of the captain and officers shift…
‘The engineering officer should be guided by requests from the captain and other officers needing power when making allocations. Quite often, he/she will not be able to satisfy all requests completely, and so must try to compromise as best as possible. (Now you know why Scotty hits the Saurian Brandy so hard…)’ [1]
Yes, I’m nerding out a smidge here. I do not apologize. For us young teenagers, sitting around the dinner table at my mate Matthew’s duplex on a balmy summer night, pretending to crew the mighty USS Hood (NCC-1703) was a mesmerizing distraction from our maths homework and listening to our parents’ debating as to whether or not the Soviets’ shoot-down of KAL Flight 007 over Sakhalin Island was going to finally instigate a global nuclear war. [2]
The first adventure that we played – ‘In the Presence of My Enemies’, that came with the original game box – only held out attention for so long. That autumn, we started playing Victory Games’ James Bond 007 RPG instead. [3] In the winter of 1984, we all switched over to playing Game Designers’ Workshop’s post-apocalypse military survival game Twilight: 2000. [4] The Star Trek game went back in its box, got put up on a shelf, and we all generally forgot that we had it.
What never left me, though, was that engineer’s console from ST’s starship combat mini-game. Decades later, when I was searching for ways to teach general IT management principles and work prioritization to my aspiring section heads, that little blue mini-game console came bolting out of my memory like a scalded cat. It struck me that the simplicity of that game-within-a-game can be a darned excellent tool for teaching new managers how to try (and fail) to balance the conflicting demands of all of their key stakeholders with their constrained resources. Here’s what I worked out:
First, tally your resources – people, specifically. For every fully-qualified team member you have, give yourself four points of ‘labour’. For every partially qualified team-member, two points, and one point for every unqualified worker. Add all of those resource units up. That’s your resource pool.
Then, mark off four parallel tracks on your mock console:
- Customer support (e.g. help desk calls, broken unit repairs, etc.)
- Systems maintenance (e.g. patch management, upgrades, testing, re-cabling, etc.)
- Solutions development (e.g. research, testing, acquisition, lab experiments, etc.)
- Security operations (e.g. log analysis, event monitoring, investigations, etc.)
Make each of the four activity tracks equal to slightly more that the total resource units that you have available. So, if you have 40 points or resources, assign each activity track 44-45 points of capacity. If you’re a devious sort, you can probably guess what’s about to happen.
Each ‘turn’ in the game equals one shift (or one day, if you don’t do 24/7 operations). Give your manager their first turn’s allocation of resource points… and then have four other players step up to fulfil the following key business roles:
Player one represents line management: she wants maximum uptime, no service interruptions, and fast customer service. It is impossible to give this player everything that she wants at any given time.
Player two represents executive management: he wants maximum uptime, no service interruptions, and zero security incidents. See above, re: impossible.
Player three represents the user community: they want maximum uptime, no service interruptions, and you to deploy all of the latest technologies.
Player five represents the customers: they want zero security incidents and plenty of exciting new solutions. If you fail to keep your solutions development at a minimum of 75 per cent two turns in a row, your customers get fickle and leave you for your competition – thereby causing the company to eliminate ten per cent of your resource pool maximum in the form of involuntary layoffs.
Finally, player four represents the bean counters: they want to reduce your resource pool so that the employee funds can be used elsewhere in the business. Any turn in which you achieve 100 per cent defence in the support area, the bean counters will reduce your resource pool maximum by ten per cent.
Every turn, after the IT manager allocates his or her resources, throw a random staff event at them. I’m thinking of a deck of external event cards, with titles like: ‘sick child’, ‘earned vacation time’, ‘violent illness’, and so on. Each personal event card reduces one of your already-allocated tracks by one full-, partially-, or un-trained resource (as listed on the card). You make a reasonable plan, but then real life intervenes and screws everything up.
Then, after the tracks are reset to accommodate people problems, break out the event cards! These should have names like ‘zero day exploit’, ‘database server bug’, ‘counterproductive OS upgrade’, ‘unexpected product rollout’, and ‘disgruntled insider’. Give each event card a minimum survival rating: for example, the ‘zero day exploit’ card might require a minimum allocation of, say, 20 points each in Systems Maintenance and Security Operations in order to survive unscathed; failure means that the IT team’s resource pool is reduced by a random number of points (roll a traditional six-sided die) for a random number of turns (another six-sided die) as the team responds to the new problem.
As an advanced rule, allow the IT manager to ‘declare an emergency’ after the event cards are drawn and demand that her employees work extra shifts, weekends, etc. A surge will grant her an additional +1d6 of resource points to allocate towards a problem area… but every surge used increases employee discontent. At the end of every turn where the manager ‘surges’, roll two six-sided dice. If the result adds up to two, then one random employee quits in frustration and their resource points are no longer available on subsequent turns. Every turn after the first that the manager surges, the ‘rage quit’ target increments by one (so, a result of two or three on the second surge; two, three or four on the third, and so on). Losing an unqualified worker hurts, but losing fully-qualified workers can be devastating.
After a couple of turns, it’ll be clear that the well-meaning IT manager can’t possibly cover all of the required resource areas adequately, and will start taking damage that she can’t recover from. She’ll eventually lose enough resources that the department simply can’t handle whatever’s thrown at them. Long before that happens, though, the different stakeholders will be incandescent with rage at her for having failed to satisfy their irrational desires; if any three of the five stakeholder players agree at the start of a turn that they’ve lost confidence in her, they can demand that the exhausted IT manager be fired. That makes for a darned accurate (and prescient) workplace simulator.
It’s not a fair game by any stretch of the imagination, and that’s precisely why it’s so instructive. The IT department manager player’s objective is to survive as long as she can. Eventually, she’ll realize that she’s trapped in a no-win scenario and that something outside of her control is going to pull the wings off the whole operation. [5] If the game is played right – and if it’s deconstructed conversationally afterwards, for education’s sake – this game can teach aspiring IT leaders the importance of pre-emptively managing their stakeholders: that is, setting reasonable performance expectations, over-communicating about what’s happening in order to tamp down discontent, and accepting that events completely outside their control (like employees’ sick kids) will sometimes derail the best of plans.
Over the years, I’ve seen a lot of IT heads come and go – some decent, some terrible. What usually separated the good ones from the awful was that essential understanding of the principles of pragmatic resource management. Good managers planned ahead to emphasize a few major objectives at a time, appreciating that the more they surged in one direction, the more they’d have to thin out their defences in all other areas. They also grasped the hard truth that it’s impossible to satisfy truly irrational stakeholders – and that it’s usually counter-productive to try. The good manager also appreciated that the harder you push your people, the quicker you burn up team morale – thereby critically weakening the entire operation.
I’m not calling the ST mini-game a perfect training tool, but I’ve never seen another tool in our industry that accurately instils the sense of existential dread and loathing that goes with trying to keep an IT outfit afloat during turbulent times. It’s hard to believe that a one-off mini-game written in the early 1980s about a TV show from the 1960s could be so useful to IT managers in the 2010s. Still, our primary responsibility to our aspiring junior leaders is to leverage any and all teaching tools that we have at our disposal in order to get them ready to replace us. I’ve used variants of this little simulation before to open my people’s eyes, and I can tell you that it works a lot better than any heartfelt lecture or painful anecdote ever did.
If you’ll excuse me, I’m going to rummage around in my archived games closet and see what other forgotten treasures I can find. Ooooooh! First Edition Car Wars from Steve Jackson Games in the original 1980 pocket box! Consider me offline until next week. Ta.
[1] Page 104, column 2, paragraphs 1 and 4.
[2] That was most definitely a thing where I grew up. For all practical purposes, it was pretty much the only thing that really mattered. I remember being absolutely convinced growing up that the Soviets were committed to burning us all to death in a nuclear firestorm. My schoolmates and I all knew that we had no chance of surviving the coming war, and that there wasn’t any point in planning for our future, because there simply wasn’t going to be a future of any of us. I find it immensely difficult now, as a grumpy old man, to explain to my own children that us 80s kids are still flummoxed and unsure how to reconcile the fact that that the Cold War ended with us all of us still alive.
[3] Yes, I still have all of those books.
[4] Still have all of those books too – both first and second editions. See previous, re: nerd.
[5] Let’s take the obvious Kobayashi Maru joke from Star Trek II: The Wrath of Khan as-read.
POC is Keil Hubert, keil.hubert@gmail.com
Follow him on twitter at @keilhubert.
You can buy his books on IT leadership and IT interviewing 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.
–
