Management lessons I learned as a dungeon master
I wasted a good portion of my teen years playing Dungeons and Dragons. (Kids, this was back when the world was young, and the game was new.) They were fun times spent whiling away the hour by killing skeletons and dodging dragons.
Our little group never got into major campaigns–we preferred “one-shot” campaigns. This way, when it was done, it was done. One of the benefits of this was that we would rotate who played as the Dungeon Master. Sometimes I was just a player on the team, but at other times, I was the master of the universe.
As I look back on those days, I see ways that being a Dungeon Master actually helped train me for managing software developers and software projects. I didn’t know it then, but I learned a few lessons that would stick with me.
Assemble the right team
Having the right skills in the group was always critical when assembling a group to go on a quest. I always found that there were two important things to think about when assembling a group of adventurers to loot a castle.
Before you tackle a new project, make sure you have the right set of skills to complete it.
Types of players
Since every quest is different, before you start the quest, you need to make sure you understand what needs to be done and the roles you need to fill to get the job done.
- Are you going to have a front end that users use? You will need a UX designer.
- Are you storing information in a database on the backend? You are going to need a DBA and a database programmer.
- You need a vision keeper, or someone who understands what is being built and sees the big picture. This is also known as an architect. As the Dungeon Master, you cannot function as a team member, so don’t pretend you can Dungeon Master and be the vision keeper. The same goes for software development. As manager, you have your hands full. Don’t try to be an active participant in the project and manage it as well.
- Of course, every team needs grunts/tanks/meat/shields/programmers–whatever you want to call them. These are the people that are going to do the bulk of the work.
As the manager, you need to make sure that your team has the right combination of skills and experience to successfully complete the project.
Size of the group
Once you know the roles that need to be played on your quest, you need to make sure you have the right number of players to fill them. Small one-shot campaigns can be accomplished by a small group of generalists. In this case, each player has a few different skills but is not an expert in any of them.
Larger quests require specialization. The tasks will be more difficult, so you’ll need experts–high-level players that can drill down and focus on one specific task and complete it better and faster than anyone else. These are surrounded by lower-level players that help out and in the process, level themselves up for the next quest.
The same goes for software development projects. You need to size the group appropriately. Sometimes, you apply the Texas Ranger’s rule, “One Riot-One Ranger”. Other times, you will adhere to Jeff Bezos’ “2-pizza” rule for teams: “No team should be larger than can be fed with 2 large pizzas.”
As the manager, it’s your job to figure out what needs to be done, so you can figure out how big of a team you need.
Just remember, the more players you have, the more difficult it will be to keep everyone focused on the goal. Spend a lot of time examining your quest, exactly what needs to be done, and the roles that are critical to fill vs. the “nice-to-haves”.
Projects need a start and an end
It doesn’t matter if it’s a one-shot campaign or a large campaign; every campaign needs a start and an end. The end is the goal, or the “mission accomplished” moment. If you don’t have an end, everybody is just wandering around.
In software projects, the starting point is usually a user request or a feature request. The goal should be clearly explained in the user’s request.
The starting point is always where you are right now. The end is the goal you want to achieve, and the campaign is how the team gets from the start to the end. As the DM, your job is to make sure your team finds the end goal. It’s not your job to tell them how to get there, but it is your job to make sure that each step that they take is a step towards the goal.
Beyond just having a start and an end, a good Dungeon Master communicates with the group. At each major milestone you need to let them know:
- Where they are now
- What direction they are moving in
- What their end goal is
Your goal is to keep them pointed in the right direction to help ensure their success.
Being in charge is a lot of work behind the scenes
A Dungeon Master has to do a lot of work that nobody else will see. This prep work helps ensure the success of the quest.
For a Dungeon Master, the prep work is understanding the landscape, the world around the group, and placing both obstacles and treasures for the group to find. You are creating the world for them to explore, so you need to fully understand the landscape before they set foot in it.
Before a group enters a cavern, you’ve taken the time to plan out what is in there and write up a detailed narrative of why they are there and why they have to go through it. You leave out the parts that may distract them and keep them focused on the task at hand and the overall goal of the quest.
Kill the skeletons, so you can get to the dragon’s lair.
As a project manager or a team manager, you have to research the project before you even start forming the team. You need to understand the goal of the project, because by understanding the goal, you can help the team reach it.
Along the way, you are going to have to keep others apprised of your team’s progress. Yes, team members can speak for themselves, but if they do that, they aren’t working towards the goal. You can help the team by removing all requests from them that aren’t directly related to the project. If a presentation needs to be made, you need to make it. If a meeting needs to be attended, you attend it. Your team may not see this sacrifice, and even if they do, they may not understand its importance. You, however, keep the team focused by removing distractions.
Wrap up
If you overthink it, the analogy will fall apart. When I was sixteen and playing D&D, I wasn’t thinking, “One day when I manage software developers…” Regardless, there are lessons that we, as managers, can learn from Dungeon Masters–important things that can help us guide our teams through their quests to complete the projects we’ve selected for them.
Just don’t forget to take the team to the pub once in a while to celebrate the victories and toast the fallen.
Interested in working with Gun.io? We specialize in helping engineers hire (and get hired by) the best minds in software development.
