I’ve been playing Dungeons & Dragons (D&D) since I was about 16 years old. It was also about that time (possibly coincidentally) that I also became engrossed with computing. Not just watching-my-fake-family-die-from-dysentery computing, but how computers worked and why the field of computing was important.
In High School, I worked with a few good friends during the day and we still had some free time. What’s a teenager to do with free time, friends, and evenings off, while still maintaining a clean criminal record? We decided to give this “Dungeons & Dragons” thing a try.
As it turns out, we enjoyed ourselves immensely. We got to escape to a world completely of our own choosing where the only boundaries were our imaginations and the roll of the dice. The collective problem solving, strategizing, and comradery appealed to our youthful minds in a way that few things previously had.
Time passes and lives drift apart, but over twenty years later I’m still playing. Even though we lost touch years ago, it turns out many of my original group sought out high technology careers. Looking back, the parallels between working in Information Technology and playing in a D&D campaign have striking similarities.
Defining Roles in D&D
Part of the deal with a new D&D group is punishing someone deciding who will be the Dungeon Master (the “DM”). Where everyone else gets to read parts of one rule book, the DM gets to read that whole rule book and two other rule books as well. Your job as DM is to provide the game bounds and guide the characters on their adventures. Done well, it’s like collective story telling with some randomness added.
In my first party, I was voluntold to be the DM for two reasons. The first reason was that I already had the first book. The second was that I played it once before years before. That qualified me as having sufficient experience: doing it once years ago and having some printed materials.
A near perfect parallel presented itself a decade later. I was a newly minted network engineer who came from a very varied background. I liked to play with and touch everything and because of that my desk was littered with a collection of books that covered all manner of things technology. A teammate was walking around one day, saw a Microsoft Exchange book in the mix, and asked if I had any experience. Since I wanted to impress the new team, I replied that I had, but it had been a few years.
Next thing I know, I’ve been asked to assist the team with re-architecting an enterprise-wide, highly available, site resilient Exchange infrastructure. I had the privilege of working with teams with all kinds of varying skills and technology concentrations. Looking back, both of these experiences drastically shaped my life and career by helping me understand being able to pivot based on the group consensus, having the confidence to be a leader, and appreciating input from others.
Party Balance in D&D
I alluded to it previously, but confidence and a little bit of showmanship are key attributes of a DM. You are the center of attention most of the time as you weave the story and outline possible paths. Understanding and enforcing the rules is important, but even more vital is keeping the players working together. This can be especially difficult based on their experience with the game mechanics, the varying personality types, and the jobs or alignments they’ve chosen for their characters.
Thinking back, this isn’t any different than working with an IT Team. There are going to be people who know more than another about a specific technology – even within the same team, each with different skills, different paths they traveled to arrive at this point in their career, and their personalities can be just as varied. Leading a team like that can be frustrating, but also incredibly rewarding. The different skills create a great “party balance” and the different levels of experience offer multiple perspectives when solving a problem.
Creative Problem Solving
Maintaining good party balance provides you with many advantages when trying to tackle any obstacle. In D&D you might be hit with an unexpected monster and you need to decide how best to neutralize this threat. In a party of all barbarians, there is only one solution: run in and smash things until there is only a pile of goo left – either the monster or your team. But if you have a varied party with good balance, you can come up with better, more creative solutions. Perhaps you have your archers launch the first volley, followed by your fighters closing in, with clerics and mages providing healing and support. All of a sudden, the dynamic shifts. You’ve come up with a solution that none of your party individually could have put forward.
Creative problem solving is just as valuable in IT. Regardless of the situation, be that a dragon in a tower or a storage array tray failure, you need to work together to try and find a solution. Pulling the teammates with the best experience and who have distinct skills together to find a creative solution is the best way to handle any given situation. I learned this during a war room meeting after a weekend outage. We pulled a member from each team to assist in diagnosing the scope, pinpointing the root cause of the failure, and plan for rapid response next time. This would have never happened if we didn’t get together and share our knowledge and experience.
Planning for D&D
Some would argue that being a DM is only as difficult as taking the time to do the reading and planning. I would argue that being a DM is knowing the proper amount of planning to keep the story moving forward. Devoting the correct amount of planning is a precarious balancing act. If you plan too little, the game can feel jarring with halting steps between the storylines for which you are prepared. If you plan too much, then you, as the DM, are less open to dynamic changes. A good balance is key for overall enjoyment and it’s sometimes a tightrope walk. Part of that balance means keeping tabs on things and keeping the game moving forward.
In a game a few years ago, my wife was playing as an elven bard. Her character would wander around with her lute and instigate situations. She was the walking embodiment of “poking the bear.” In one particular session, the players were stuck with “analysis paralysis” – the inability to make a decision because there are too many variables – when determining how to form up or what to prepare or what to do about this door. My wife’s character (being bored with the situation) would kick in the door, strum a few notes, and run to the back of the group.
Whether she knew it or not, she was acting as my Project Manager – keeping the process moving. Instead of the DM constantly prodding the characters to keep moving forward and keeping them on task, one of their own rank would do so. It felt less controlling to the players. Occasionally, she would suggest outlandish solutions to problems and became the token “chaos monkey” of the party, making decisions to keep things interesting. Had I over planned the adventure, I wouldn’t be able to adapt to these unique (and often comical) changes to the story. She added the randomness that you actually get with real-life teams and personalities.
CRIT! Unplanned Good/Bad
Randomness is a part of life. This has widespread areas of affect: from human interactions to chaos theory. To make Dungeons & Dragons more lifelike, it needs to inherit this randomness from real life. This is where the dice come in. The one that’s used most often is the 20-sided die (referred to as a d20).
On any roll of a d20, you have a 5% chance to get any number. Within the game mechanics, there are also modifiers. These are numbers added to or subtracted from a roll based on character features. So, if your character is especially proficient with a bow and arrow, you might roll one d20 die, get a 16 from that roll, and add 4, with a result of 20 (1d20+4). The modifiers go both ways. If you character has no idea what a bow is, they might throw the arrow like a javelin and get a -4 modifier imparted. For the same roll, you’d have 16 minus 4, yielding 12 (1d20-4).
However, there always needs to be a chance for success against all odds, or a failure against all odds. These are “natural” rolls of 20 or 1 – “natural” implies that this is what the die shows – no modifiers. Because of the significance of these rolls, a natural 20 is called a Critical Hit and a natural 1 is called a Critical Fail.
Modifiers in IT
You can also try to stack the deck (mixing metaphors) with modifiers within IT. Did you do great planning? Then you get a +2 to the chances of the action being a success. Did you try to patch a system within production without testing it in development first? Sorry, you just got hit with a -4 modifier. Long story short, if it doesn’t seem like a good idea, it probably isn’t.
Critical Hits in IT
Sometimes you or your team just hit something out of the park. Yes, I’m mixing metaphors again, but you get the point. You didn’t plan for this task to go as well as it did. You’ve moved 1,000 mailboxes during the night with no downtime. Your team executed a zero-downtime upgrade of a SQL cluster. Your coworker applied configurations to 200 WAN routers with no blips. The odds were stacked against you, but despite it all, you were successful! This a Critical Hit!
On the chance that you’ve encountered one of these rare events, be sure to celebrate. Do a little dance, take everyone out for a lunch, let your management team know about it, whatever you do to mark accomplishments. These are rare events and should be celebrated.
Then again, there’s the other side of the coin die.
Critical Fails in IT
In game, when you have a critical failure, whatever you are trying to do fails… epically. Let me set the stage: everyone in your party is fighting on a bridge and engaged in heated combat when you see a troll step out from behind a structural support. The troll hasn’t seen you yet, so your character tries to push it off the bridge. You roll your d20 and end up with a natural 1. Instead of pushing the troll off the bridge, you lightly caress her arm and she giggles. This is an epic failure and the scope of it is only bound to DM discretion. They are commonly some of the most comedic (or tragic) parts of the game. The troll situation was comedic, but for examples of tragic, look up “dice shaming.” Go ahead, I’ll wait.
In IT, epic failures take different forms. You’ve planned your change out to the nth degree. You’ve gotten sign-off from all the necessary parties, and you’ve make all affected parties aware. Then you go to pull that blown hard drive out of that RAID array… and you pull the wrong one. Congratulations, you’ve just shredded the data on that array. Epic failures are always possible. Planning and preparation can give you a modifier, but there’s always a chance to roll a natural 1. Recovering from an epic failure requires quick thinking and decisive action, but the best thing you can do is communicate.
Communicate with the department and the affected parties. Clean, clear communication of the issue and your plans for recovery are the first, best thing you can do after getting an epic failure. Here’s where every member of IT gets to be their own DM. It’s up to you to decide the next move. Make it a good one with transparency.
Short-Circuiting your Adventure
I’ve noted that preparation and planning are some of the hallmarks of both a good DM and IT professional, but sometimes planning gets short-circuited. In the past, I’ve spent hours working on a campaign with intricate details, a slowly building storyline, interesting character interactions, and a clear path from point A to B to C and so on.
Then we sit down to play this epic tale, and the players choose to follow the white rabbit instead of the obvious path in front of them and jump immediately to point J. That’s it. A small change and they’ve completely gone off course. In the past, I’ve had this go one of two ways: the group takes a petty diversion and makes it more than it’s supposed to be or they’ve jumped ahead in the story so much that I don’t have anything else planned. As the DM, you can either throw up your hands and walk away, force them back on the “right” path, or see where the adventure leads.
One of those avenues reminds me of scope creep in IT Projects. You’ve outlined everything in a beautiful waterfall plan and the team starts taking side-trips and tacking on new requirements. The adventure of discovery is upon you! Keep going! Let’s see where this will end up. Will your quest to swap out a power supply lead to the adventure of replacing all the UPS’s in a data center? Who knows? Adventure awaits!
The clear answer here is “within reason.” You’ve planned one change and now people are adding more and more to that change request. Where do you draw the line? I can’t answer that for you, because it’s different for every scenario, but you should be open to change. Embrace it where you can and push it off where you cannot.
The flip side of this scope creep is having your entire plan thrown out and being asked to “skip to the end.” Just like in D&D this leaves you asking, “what’s next?” and not having a clue. Maybe you’ve only planned for five steps and you need to jump right to step six. Can you plan for this? Probably not. About the only thing you can do it plan for the unexpected.
Looking back, the same solution presents itself for each problem: plan for the unexpected. This applies to the players, the DM, and the IT Professional. There’s always going to be another tree in the forest, and there might be a goblin archer behind one. Plan for these diversions, but don’t let them pull you from your goal.
Flood of Kobolds vs. Epic Boss Fight
I had a group where I was running a dragon-themed adventure. I know what you’re thinking, “An actual dragon in a Dungeons & Dragons game?!? CRAZY!!” but in this case the dragon was more than just the final set piece. It was the mastermind behind every other obstacle the party encountered.
One aspect of the dragon’s machinations was to repeatedly direct hordes of kobolds at the party. For the uninitiated, kobolds are the punchline of every “you’re so weak” joke in D&D parlance. They are small, weak, stupid, slow, and not particularly dangerous. The one thing they have going for them is that there are millions of the little buggers. Think of them as D&D’s equivalent of a DDOS attack – annoying but not overly problematic if you’ve taken the necessary precautions.
Now, in the game, the dragon would send swarms of these guys at the party almost every step of the way. Worse, the dragon directed their attacks so they were more coordinated and sophisticated than the party expected. The result was that each encounter felt like a huge battle that drained the party’s resources. And the further in the party advanced, the harder each encounter became. The party got experience, rewards, and time to heal wounds. Each time they got better and better and handling the situation. Unfortunately for my players, these were just the opening volleys.
The big battle was, of course, against a dragon itself. Sadly, it was nearly a total party kill (TPK) for the group because they got overconfident based on their previous encounters. By the final fight, the party had realized the dragon was commanding the kobolds. They assumed that because they had defeated the dragon’s tactics in each previous battle, it had nothing new under it’s… uh… wings… tactically speaking. Confidence is great – overconfidence less so.
I’ve seen the same thing in IT. Technicians get cocky thinking that they know everything and bite off more than they can chew. This is typically something that green IT people do, but they don’t have exclusive rights to this failing. The thought that “in a perfect world it will go just like this” falls on its face when you realize that there’s no such thing as a perfect world. New IT people sometimes don’t have the wisdom to think, “maybe this isn’t just one-degree harder than the previous thing I did.” If there’s a lesson to be learned here, it’s that you cannot win every fight with the same skills you already have. Learn new ones and evaluate your scenarios before rushing in. Sometimes you need to take a step back and reassess the situation. Understanding the need to regroup is something that comes with experience.
Epilogue
“Has running a D&D game actually provided me with any life skills?” The answer, obviously, is a resounding “Yes!” (with accompanying cries of “Huzzah!” and “Well met!”) So much so, that I would have no issue putting a few things on my professional resume.
- Meet with peers for scheduled creativity and conflict resolution exercises
- Assisted multiple people with gathering experience for both character and skill development
- Learned to quickly assess situations and collaborate on best solutions
- Strong research, planning, and interpersonal communication skills across a diverse team with varying skill sets
So, sit down, roll some dice, and have a great adventure with both D&D and IT at the same time.
This was originally part of a four-part post to THWACK on Geek Speak.