The RPG Player’s Guide To Managing Development Teams
A good job is like a good game: you know what your goals are, all the tools you need at your disposal, and there’s a fair bit of challenge.
In the next few minutes, I’m going to unpack an assertion: that engineering management roles are way analogous to RPG classes. I hope it’s mildly useful.
Let’s roll.
A Software Development Team As an RPG Party
Both groups are composed of differently-skilled individuals acting towards a common goal (or a quest, if you will)— each with their own role and motivators.
Success is usually a function of how well the party members execute on their roles, and how well everyone works together. And hey, you’re gonna wanna make sure the party has every role it needs to succeed. Just as a party of all-warriors is suboptimal, you need a mix of disciplines and skills within a team to deliver on a project.
Managers Don’t Do DPS
The reason I underscore this fact is that I firmly believe that as a manager, you are not the damage dealer. It’s the rest of the team that executes and actions against mobs, in the same way that it’s the developers, designers, QAs, and BAs doing the work. Your role is facilitation and support — not the execution of progress.
There’s a lot of ways to support a team, and you’re going to want to be able to switch up your role depending on the problem space the team is facing.
Role 1: The Healer
In your career as a manager, you’re going to find some injured teams: teams that just work really badly, or where everyone hates being at work for reasons that are intrinsic to the team. Given a brief period of time, people are going to leave: so you’re gonna need to move fast.
Time to cast Healing Word.
Use team debuggers. Safety checks become essential. Team health monitors are good way to figure out what the team temperature is — so figure out the pain points as quick as you can. What’s hurting the team the most right now? Every problem is important, but some more so than others.
Prioritize 1-on-1s. Where is everyone at? What’s making people unhappy? Are people thinking of leaving? You need a finger on the pulse right away — so make sure you’ve got your coffee budget intact and your ears ready, so you can ask, “How are things for you right now?”
Stop the bleeding. Index towards activities that pad morale and increase team cohesion. Social contracts need to be assembled as soon as possible. Tradeoff exercises are good for building team charters. Stack the team activities towards ones that build empathy and rapport.
The key here is to respond right away. Maybe you have some disillusioned engineers wanting to jump ship. Maybe there’s animosity among members. Get in fast, pull out the tourniquets: no one deserves to be in a place they don’t want to be.
Role 2: The Tank
With hope, you’ve gotten the team to shore. Perhaps not wholly healed, but not bleeding and leaking out talent. But a team does not exist in a vacuum — so you’re going to want to find out what they’re doing, or how work gets created. Time to play the Tank role.
The term “shit umbrella” gets bandied around a lot, but what it means is that it’s good to be the point of contact for every team-related query or stressor for a slice of time.
You do this for two reasons:
Reduce cognitive load. Switching contexts is expensive. Teams will sometimes be buried under a torrent of walkups and direct requests, and you want to give developers some breathing space so they can focus on the things they’re good at.
Get an understanding of the shape of work. This is significantly more important, as it lets you classify the work that a team gets, and fully empathize with what kind of work the team receives. You’re going to want to ask three questions:
A.) What’s the impact of the work?
B.) When does the work need to get done?
C.) How complex is each piece?
Once you have a good mental model of how things are, it’s time to move to the next phase:
Role 3: Crowd Control
“Crowd control” (or CC) is a role in an RPG party that’s concerned with limiting the number of mobs actively fighting during an encounter. From a management perspective, this means making sure that you’re working a sustainable pace and working on a finite number of the most important things at any point in time.
So how do you do this? Well, you dump the file and spread out the contents:
Categorize the work. Everything needs to get done, but some things more so than others. So you’re going to need to do a comprehensive inventory of the work that the team gets, and use a rough sieve to slice and dice. I like to categorize by how soon we should do things based on how much effort vs. impact they would have.
Slow down work. “Casting” crowd control spells in an organizational context is roughly analogous to using the dark powers of bureaucracy and policy in your favor. You can apply process as a means of slowing down work: perhaps initiate a ticketing or request system for non-urgent needs, or a review system for slowing down architectural deviations. You do this not to delay things from getting done, but to make sure things get done at the right time.
Make a list of work you don’t do. This is significantly more important in internal groups, where you end up with catchall teams that do a bit of everything. Creating a line between what you are and are not accountable means that a lot of conversations get cheaper. You have less work turning up on your doorstep that you don’t need to do.
Role 4: Supporting Buffs
Being an umbrella for your team is good, but the ideal state is that everyone has their own tiny little umbrellas. This means that over time, you need to enable your team members so that they can handle work without your active participation.
Individually-executable rulesets. It’s good to start with creating rulesets of what the team is supposed to do and when — but it’s better when everyone is enabled to make that decision. This means that over time, you’re going to want to empower everyone.
Start by having people in the team make decisions. This can take a shape of a question, or being absent in meetings as a deliberate choice. You’re going to find that people are more willing to be accountable for the things they can have a decision on.
Teaching and Learning. Actively enabling learning means that you have developers who are more equipped to deal with whatever problems come. Actively enabling them to teach other people means that people grow their coaching skills, while at the same time reducing the work that your team needs to do.
Headcount. As you get a better idea of the internal system of work within the team, you’ll also get a feel for how many people need to be there.
Role 5: Scouting Ahead
Getting a team to stable is hard work. But I find that it’s worth it: if only for the satisfaction of being able to transition my efforts from inward-facing issues to external-facing ones. This means changing your question from: “What needs work in the team?” to “What’s coming up?”
Just as a rogue can roll for perception to check for traps or opportunities, I hope you get to the point where you can proactively plan as opposed to reacting to stimuli. Where most hygiene factors are exhausted; and the only thing left is to leave people to do the work that they love doing.
Everybody does the best job that they can, with the knowledge, time, and resources available to them. A manager’s job is to play the game in a way that gives everybody a wealth of those things.
Role Meta: Management as primarily a DM Role
I hope this was mildly entertaining. For all intents and purposes, I’ve just added candy to what is otherwise a fairly known conceptual framework:
I just added fireballs to it.
I also have some pretty core beliefs that I’m trying to unpack here: about the role of management not as an executor or active participant of play, but as being the enabler tof it.
Your win state is not to finish the campaign. Your win state is for everyone to play a round where the team enjoys accomplishments that they’ve earned. Where everyone gets to finish, take a look at everything that they’ve done, and bask in the laughter and pride after a couple of pints in the Guild tavern.
That is, until the next quest comes in.
