15 software development lessons I learned from Dungeons and Dragons

I started playing Dungeons and Dragons in about the fifth or sixth grade.

I didn’t get good at it for a while, but once I did, I didn’t play much longer (insert reference to “The Best Days of My Life” here).

Dungeons and Dragons taught me a few lessons that I didn’t realize would turn out to be great life lessons, until I was much older. This childhood game taught me life lessons that I would eventually apply to the business world – more specifically, the world of software development – and I know I’m not alone.

In fact, there is a distinct possibility that many a developer got their start scoping out character sheets, and many a Scrum Master began as a Dungeon Master.

Here are a few of the lessons I took away from those carefree days. And yes, this image is from a box set sitting on my table at home. Don’t judge.

1. Build a great campaign, and if the game is good, expect your players to break it.

In software, we design workflows. Then, users take routes we never thought possible.

You build a product, sell the product and potentially service the product long-term. Maybe it sells, maybe it doesn’t – but if you’re not ready for the sales to happen, you won’t sell that much.

How much work do you put into building a campaign, or game, in Dungeons and Dragons, if the characters are just going to go right off your script? How much effort do you put into building a business if the customers are just going to buy something from you that is completely different than what you thought you were going to sell?

These are the same questions, and there’s no right answer to either (although there are many wrong answers). Understand that when momentum strikes, if you don’t have a good campaign built that is flexible, you won’t maintain that momentum.

And if you haven’t thought of all the various routes a user can take around your software, you’re going to have a bunch of lost paladins mucking around in swamps with no monsters!

2. If you have to stop the game to look up the rules, your momentum is lost.

Games are always more fun when we understand the rules.

When you have to stop and look something up, the attention of gamers can get lost on distractions – like potato chips.

Similarly, the attention of someone using your software is lost when they encounter an exception or error, and have to wait for a patch while you reengineer the whole product.

The more resilient your software, the more likely users will ramp up their use of the product quickly, and not have their attention wander when you have to look up how to properly figure out what saving throw is required to keep from getting crispy from the breath of a red dragon.

3. Engage your users.

There’s not much reason to play Dungeons and Dragons alone. If the game isn’t fun, you will invariably not have many people come back for a second or third campaign.

People who use your software need to be engaged. Products and companies these days need to have a personality.

Sure, you might make a great widget, but if it isn’t fun to come to work and even make, sell or support that widget, then you’re going to have a much harder time getting those things done.

Fun brands and software, just like fun games, drive engagement – and engagement is one of the easiest ways to amplify your development efforts.

4. You gain experience incrementally, but it shows in bursts.

In Dungeons and Dragons, you gain experience points for doing things. When you accumulate enough experience, you go up a level. We learn lessons along the way (like how a Level 1 Cleric learns not to tackle a blue dragon alone).

In development, we slowly work our way towards a new level.

I was recently in a meeting where someone said our software development organization had reached a whole new level (and given that we recently doubled the staff of our development teams, it really has). In development, you work your way to a new level, learning lessons, training staff, expanding, paying down tech debt, etc.

But all of a sudden, you realize “Holy crap, we can now cast fireball spells!” When did that happen?

Sometimes you don’t even know – but it’s usually obvious to everyone that a gap was closed, a threshold crossed and it’s time to start building momentum for the next level, tackling more difficult monsters, arming up with better weapons and maybe even picking up some new NPCs along the way!

Can you say it’s time to ship a major release?!

5. To sell, you need to be confident.

When it’s your turn in a game, you may talk as your character would (I’ve heard some of the worst, yet most endearing accents ever in these games.) The more confident you are, the more immersive the game.

Without confidence, a Dungeon Master is likely to get walked all over.

Most jobs in a company have way more of a sales component that most employees would like to admit.

Product management, software architects, and development managers are the obvious Dungeon Masters, but every developer is going to have areas where they want to do more (paying down tech debt vs. building a new feature being a common one) – and selling that to the team is half the battle!

6. Some players are just going to be more engaged than others, no matter what you do.

Different people want different things out of a game of Dungeons and Dragons, their jobs and life in general.

When I was taking MBA classes at Cornell, they referred to this as different people having their own motivators.

These motivators influence how impactful various initiatives are. For example, some respond well to financial incentives. Others, to social interactions or pats on the back.

Some players have a math test the next day and are going to miss a game. Others are ridiculously into the game (common with developers).

Just because you put a lot of work into developing a campaign or a new button in a product, that doesn’t mean that others are going to be into each and every game. Everyone will have more fun if the expectations for engagement with a given initiative are tempered and any involvement is looked at positively.

7. Don’t dominate the game.

Everyone should have a say in how games go. There are going to be natural alphas in any group – but try to give everyone ample time to play and talk about what their character is doing.

If some people don’t have that much to say, that’s fine. Just routinely return to them and give them the opportunity.

This is how any game, meeting, brainstorming session, or retrospective can be run.

If one player is dominating the game, it’s a great idea to step in and keep them from doing so. How you go about doing so will become a skill that you hone for decades.

And, try not to be that person who dominates.

8. You are invariably going to outgrow the game.

People don’t stay in the same position forever. You need to build a growth path. Likewise, you don’t want your level 5 Drow Elf Ranger to stay level 5 forever.

You want to be prepared for how the game will play out with higher level characters, and maybe even keep a funnel of lower level characters and employees who can work their way up into higher positions. And when a player decides to leave the game, you need a succession plan.

This is easier in Dungeons and Dragons than in a development team.

Sure, you can switch classes, just like employees can switch departments, but it’s a pretty linear path for most in the game. In the real world, everyone will have something different they want out of a job and it’s the job of a servant leader to help them get there, even if that means helping them soar to new heights at another organization.

Of course, it’s best if you can provide a growth plan that keeps your awesome people in house – but sometimes a player is going to go off to college. Maybe they’ll come over and take over as the Dungeon Master when they come home though, so stay in touch.

9. Morale is optional in Dungeons and Dragons, but not in a development team.

Morale was a slightly more advanced feature for Dungeon Masters.

If a creature or retainer fails morale check, it will disengage from a battle and retreat.

If it sucks to work at your company or on your team, the team will do the same (maybe they’ll spend more time catching up on Clash of Clans than finishing that Hibernate implementation).

If you don’t work on morale, you won’t find yourself with talented developers for long. After all, developers can find a new job faster than you can take out a kobold with a pair of Drizzt Vorpal Scimitars, +4.

10. It’s about the journey, not the destination.

Sure, you could rush through a dungeon or a forest of kobolds in record time. But why?

Killing all the kobolds is going to get you experience points, which add up until you get to the point where you can tackle golems and orcs and dragons.

When writing code, we must be thorough. I find that I can get 90 percent of a project done in no time.

That last 10 percent is the hardest – but also where I learn the most.

It’s also where others can see the polish.

You obviously need to complete projects, but it’s the journey towards all of your goals and the learning process that really matter. If you’re rushing through everything, it will show.

Plus, there’s usually a low chance you’ll get some kind of magic item off a kobold.

11. Eventually, your fighter has to work on more traits than just strength.

The easiest character to play is usually a fighter, because you’re just a “tank”. You can walk into a room and fight and kill monsters.

In Dungeons and Dragons, each character has a number of different abilities – things like dexterity, which helps a thief to pick locks and helps characters to avoid getting hit. There’s also intelligence, wisdom, constitution, charisma and strength.

Each class of character will need different abilities to be higher than others.

As you level up, you receive adjustments you can add to abilities.

Naturally, a player will work on the abilities for their class first. For example, if you have a fighter, you’ll increase strength and constitution (which gives you more hit points), or if you have a thief you’ll work on dexterity. But as the character progresses, you’ll invariably work on different abilities to unlock more advanced features of your class.

The same is true at work. Let’s say you write code for a living, which many consider the magic-user of the business world these days. Eventually, you may choose to manage a team, become a Scrum Master or manage products.

For each of these, it will greatly help if you’ve dedicated a little time to working on your charisma ability.

So while public speaking and management classes might not seem all that awesome for a code monkey, they will suit you well later in the game of your career.

12. The more junk you have, the slower you move.

Each item that your character finds in the game will weigh you down a little. Eventually, you’ll have to choose what to carry and what to leave behind. And sometimes, you’ll find yourself leaving behind things that you fought huge battles with monsters to attain.

It’s hard to let go of things, but sometimes you have to.

At work, you might have projects that you want to continue but have to let them go to move into a new position, or you might have equipment that you love but can’t keep. You might have data on your computer or mobile device that’s just wasting space, or you might have variables that are hogging up valuable memory.

Keep in mind that there’s a weight to that data. Learn to let things go.

Sometimes the character simply can’t move to the next room with a massive bag of treasure on their back.

13. Diversity is key.

A party of six fighters really isn’t going to make it far. Nor six clerics. You need a couple of fighters, a cleric (to heal everyone), a magic user (maybe an elf), a thief (likely a halfling), and more.

A well-rounded adventuring party is key to the success of a campaign. The same is true for development teams.

Different experiences and different backgrounds bring different ideas and perspectives – and also bring everyone’s game up a notch. Of course, sometimes your half-orc rogue will spar with your paladin, but the team is better for having everyone together.

14. Sometimes you have to retreat.

A fourth level barbarian walks into a bar…

It sounds like a joke, until it ends with “and gets shot with lightning by a level 36 drow lich-king”.

Have an open mind. Be creative, but if your initiatives aren’t working out, get out of the bar, before you get lit up.

Having said that, let things play out.

Sometimes the lich-king just hits you with a riddle and might give you treasure rather than have you dual it out.

Software development should be about trying new things. Be prepared to change course and don’t be afraid to admit that you were wrong.

15. Sometimes you get a critical miss. Sometimes you get a critical hit.

In Dungeons and Dragons, if you’re trying to stab a monster, you roll the dice to see if you hit it. There are certain numbers on a dice that might have your character inflicting extra damage, because you hit an artery. Then there are other numbers that might cause you to actually stab yourself.

There’s a certain amount of chance to everything we do.

Maybe a critical miss is to get fired by your biggest customer for a terrible defect – and maybe a critical win is to have that new feature result in a ridiculously large number of new customers.

I’ve seen it all. Sometimes things backfire. The best plan is to have a backout plan – and be prepared for the critical hit pushing your team forward a year or two with one deal. If you don’t try, you might not get it!

There are so many direct correlations with software development as well – the way that you run a game, the rules that you set out and the NPCs (demons, anyone?) are just a few.

Hopefully these tips give you fond memories of bad hair, ill-fitting clothes, and some of the best times with your friends.

And maybe they help you next time you’re in a standup and need to get a treasure chest open so the team can split the loot!