Dungeons & Developers: 5 Traits of Great Tech Leads & Dungeon Masters

There are a lot of different kinds of nerds in the world. Some nerds are programming wizards, harnessing the power of arcane languages to create awesome applications. Other nerds fancy themselves more literal wizards, rolling handfuls of polyhedral dice to determine how much damage their imaginary spells inflict on imaginary monsters. And then there are nerds like me, who do both. Playing D&D and engineering software each involve team collaboration. As a result, my dungeon mastering experience has made me a better engineering leader, and I think it can make you a better engineering leader too.

Tech lead by day, dungeon master by night.

A “tech lead” at Conductor is a leader of a small team of software engineers called a “feature team.” The tech lead works with the Product department to decide what the feature team will be working on and when that work is forecasted to be finished. The tech lead is also ultimately responsible for the architecture of the solutions created by the feature team. Some organizations call this role “development lead,” “programming lead,” “lead programmer” or “scrum master”.

A “dungeon master” is a special role in the game of Dungeons & Dragons (D&D for short). D&D is a roleplaying game in which friends gather around a table and play the roles of fantastical heroes such as wizards, barbarians, and knights. A set of rules and some funny-looking dice are used to determine what these adventurers can do, and how successful they are when they do it.

One person at the table is the Dungeon Master (or DM for short). While everyone else plays a single character, the Dungeon Master plays everyone and everything else. Do the heroes get some good gossip from the bartender? Are they ambushed by goblins? Is their journey hindered by foul weather? These are all questions that the DM answers about the world the heroes live in.

Even if you’ve never picked up a 20-sided die in your life, you might be able to learn a few things from D&D about how to lead a team of engineers.

1. Engineers and gamers want to succeed. But they need the right amount of challenge.

Ben: My Barbarian swings his greatsword at the evil wizard. We’re running low on healing potions, so I sure hope this works!

(Ben rolls a 20-sided die — it lands on the number 18)

Biana: It did. Your sword strikes true, killing the foul necromancer just as he was about to finish his terrible ritual!

A common misconception about D&D is that the Dungeon Master is trying to win, or to beat the players. That’s not actually the way the game works; a good DM wants to see the players succeed. But a good DM also knows that, for the game to be fun for everyone, the players need to feel challenged. As a result, DMing is a subtle and intricate balancing act.

Finding the right amount of challenge is also a balancing act for a tech lead.

Biana: We can definitely finish the new login screen this sprint. But doing the pie chart as well would be too much work. How does everyone feel about the new login screen and the API endpoint for the pie chart? I think it’s aggressive, but do-able.

When a team commits to more work than they can handle, the result is either failure to deliver on schedule or stress for the team as they scramble to finish.

Under-committing is preferable, but still not great — the team is sending inaccurate messages to the organization about how much they can deliver, and possibly not pushing themselves to deliver as much as they could. Tech leads, like Dungeon Masters, are responsible for finding the amount of challenge that inspires their team to feats of greatness, but doesn’t discourage them with too many shortfalls.

2. If you hold back information, you hold back innovation.

Biana: The cavern is dimly lit by glowing crystals embedded in the walls. There is an unpleasant smell here, like something burning. In the sand on the floor you see many claw-like footprints, leading deeper into the cave…

D&D players want their characters to overcome obstacles. But the only source of information they have about the world their characters live in is the DM. She explains what the characters see and hear — what the king decrees, what the dragon does when the heroes stomp into its den, etc.

No matter how many magic weapons and healing potions they have, they can’t beat the bad guys without information.

Biana: I sent out an email with some information about the services we can use in the API endpoint for the pie chart. If anybody has any questions, let me know. For now, I want to take a few minutes to explain the value our users will get from the chart…

Engineers need information too. In a healthy organization there are lots of ways to get that information, but the tech lead is in a unique position to support them. By dispensing knowledge to the team about the business problems they are trying to solve, the specific requirements of the features they are building, and the tools and resources available to them, the tech lead is giving them a powerful weapon to help them overcome the monsters lurking in their projects.

3. The devil is in the details — keep gamers & devs focused on the big picture.

Biana: The Elf Queen seems hesitant to help you in your battle against the goblins.

Tim: Okay. Uh, I don’t really know how the Diplomacy skill works. I think I have a charisma bonus… and, er, maybe my Ring of Persuasion will help…

Biana: Don’t worry about the rules for now. Tell me how your character is going to convince the Queen and then I can help with the rules.

D&D players often have an attention to (and even a love of) details and minutiae. Some players make a hobby of poring over the rulebooks between games to really immerse themselves in the gameplay.

But a D&D game can grind to an unsatisfying trudge when the weight of the details and minutiae become too heavy. A player desperately trying to remember what rules give them what bonuses in what situations can lose sight of the most important thing: having fun pretending to be an awesome adventurer in an awesome fantasy world.

The most important thing for a software engineer, on the other hand, is making reliable, maintainable solutions to the problems presented to them. This usually means paying close attention to detail. But sometimes details can become a distraction.

Tim: I’ve been trying to get the login form to layout correctly for an hour. This field just isn’t lining up.

Biana: Yeah we’ll need to address that before we release it. But I suggest we move on for now. Let’s get the validation and submission working and then we can come back and knock out the layout details.

Once again, the tech lead is in a unique position to help. A good tech lead stays focused on the big picture and helps the team do the same. The tech lead can, for example, help engineers see that they are giving ground on code quality by getting hung up on delivering on all the details of the feature, or — conversely — that they’re getting too hung up on writing beautiful code and not focusing on delivery. There are lots of details in our line of work that are critical in moderation, but harmful in excess, and the tech lead can help engineers understand the difference.

4. Don’t limit your team or players to just your imagination.

Biana: The goblins snarl and brandish their spears! One of them grunts something in Goblin language, and they begin to advance towards you.

Ben: Hey, wait! I know Goblin Language. Maybe I can reason with them. Maybe we don’t have to fight!

Biana: Interesting! Okay, what do you say to them?

DMs sometimes have a preconceived idea of how the players will overcome a challenge they are presented with. The very worst DMs can really frustrate their players by enforcing that preconception.

This phenomenon is so notorious in the roleplaying game community that it has a name: railroading. These DMs only allow the players to proceed if they stay on the “rails” of those preconceived solutions. The very best DMs are open to a wide variety of solutions. The players want to sneak in through the sewers when you were expecting them to barge through the front door? Awesome! Roll with it.

Tech leads can develop similar bad habits. At the end of the day, it’s their responsibility to deliver the right solution to the problem. So they might come up with a solution by themselves and not look for input from their team. This is not only frustrating to the team, but dangerous too!

Biana: Of course we’ll need to store the information being submitted by the user. I have some ideas about what the MySQL schema will look like.

Ben: I was actually wondering if Redis would be a good fit for this.

Biana: Oh, interesting. Tell me more…

A good tech lead knows their idea might not be the best, and might even have shortcomings that come back later to haunt the team or the entire organization! So a good tech lead is careful not to “railroad.” She gets the team involved in the brainstorming and design process, and encourages the whole team to review each other’s solutions and give honest, constructive feedback.

5. Good tech leads and DMs delegate.

Biana: The Vampire rises from his coffin…

Tim: Oh! I’m going to use my cleric ability “Command Undead!”

Biana: Cool. You know which dice to roll, right? Also, can someone keep track of combat rounds for me?

Ben: I’m on it!

This is the nerdiest sentence you can possibly say in the English language: “Let me tell you about an advanced Dungeon Mastering technique.” But seriously, let me.

Rookie DMs make the mistake of thinking they have to do all the work: they have to crunch all the numbers, they have to know all the rules for every possible situation, and they have to provide the snacks. But as a gaming group becomes more experienced, comfortable, and cohesive, an advanced DM can (and should) start delegating.

Let the players learn the rules for their characters. Let the players bring the snacks. Heck, let the players start telling you what kind of challenges they want to face. All of this will get the players more immersed and involved in the game. It might even give them the confidence to become DMs themselves some day.

Similarly, a good tech lead knows when to delegate. There’s a lot to manage as a tech lead. Between keeping tabs on the backlog, meeting with the Product Owners, managing the meetings, making sure everything is on schedule, etc., etc. There’s no shortage of things to do. As the team gets more cohesive and comfortable, some of these responsibilities can be distributed.

Biana: We should probably have a meeting with QA about this feature. Tim could you schedule that for me?

Not only does that mean less context switching for you, it also means the team will be more involved with the process, more familiar with the business needs, and maybe even train them to become tech leads some day.

At first glance, software engineering seems to have very little in common with D&D. But creating software, unless it’s being done on a small scale, is first and foremost a collaborative process. You can be an awesome hacker with all the knowledge and skill in the world, but without great leadership and great collaboration, you won’t be able to create great software as part of a team. In that way, every collaborative activity has analogs to software engineering. For me it’s Dungeons & Dragons. For you it might be a team sport, a rock band, an improv theater group, a writing workshop, a World of Warcraft guild, etc. I encourage you to take a look at your hobby the way I did with mine. Think about what makes the group work well together and how the leadership enables the group’s success. I guarantee you’ll find some insights about how to be a better engineer or leader of engineers, just like the ones I found from my geeky pastime.