I couldn’t find any proof, but I would bet that the % of software engineers who played computer games is much higher than the average population. If you never did, you’ll probably find this article stupid, so see you next week.
Today, we are going to build an engineering dungeon party.
The exercise is useful for every EM (even if you don’t like games for some reason).
Ok, so here’s how it goes:
Thanks Unblocked for sponsoring today’s article!
Every year, new AI tools promise to make developers more productive. But the biggest blocker to shipping software isn’t writing code. It’s usually about finding the full context to make the right technical decision:
Developers lose 8+ hours per week hunting through Slack, Jira, and Confluence
Senior engineers get pinged 10+ times a week for answers they’ve already given
New hires take 6+ months to become fully productive
Unblocked turns scattered knowledge from GitHub, Slack, Jira, and Confluence into clear answers your team can trust. The result is faster onboarding, fewer interruptions, and autonomous teams that stay focused.
Imagine you are tasked with building a new engineering team. Here are the requirements:
You don’t know in advance what type of company/industry you’ll operate in.
The team should be built to work YEARS together.
There will be 5 engineers on your team.
How will your dream team look like?
Optimizing for DPS
Many companies and EMs choose to go with a DPS (damage per second) team. They basically try to hire the strongest engineers they can find and squeeze the most out of them.
This might be the right approach for some companies (crazy growth AI startups), but I believe that for 99% of EMs, it’s the wrong approach, even assuming you have the budget for it.
Such individuals are often looking for the toughest challenges, and are very hard to keep satisfied. Look at all the chaos in OpenAI/Meta talent wars.
Instead, build a balanced dungeon party
Every game has different races and classes, but it’s common to have at least 3 basic roles in a party:
The tank - takes damage, doesn’t deal too much.
The DPS / damage dealer - the one actually killing the boss.
The healer - making sure nobody dies.
There are also rogues, wizards, archers, paladins, and tons of creative things.
There is a ton of research about how diverse teams are delivering more impact, are happier, and make better decisions (for example - Diverse teams made better decisions 87% of the time, and those decisions delivered 60% better results).
The best engineering teams I had the luck to work with had engineers with complementary skills, who were not clones of each other.
Going back to the initial challenge - let’s build a 5-person engineering team that will perform for years in any circumstances.
This is just my personal take, nothing scientific about it! It’s supposed to be a fun exercise, and a useful model to think about your team’s composition (and where you might have gaps).
1. The warrior
Level: Mid-senior+ (leaning toward senior)
In every team, you need someone who can take on the hardest problems and debug the nastiest bugs. The ones you will ask to handle that complex integration and the memory leak that no one can fix. They enjoy their craft and live for those moments.
They usually have experience from previous companies and have seen a few things.
The best ones also spend a significant amount of time mentoring others.
2. The tank
Level: Junior-mid.
The engineers who get clear requirements and execute consistently. They are still in the early stages of their career, and have a lot to learn.
They don’t complain, don’t chase shiny objects, and are very reliable. Pair them with a warrior, and they’ll take care of all the ‘boring’ things the warrior will leave behind.
3. The healer
Level: Mid-senior.
An ideal healer has 2 sides (at least imo):
They are impact-driven. They care more about the business side, are emphatic, and like to talk with customers.
They are great with people. Your other engineers usually confine themselves to them, and they are very generous with their own time.
They’re the glue that keeps team morale and communication healthy - both inside and outside the team.
(and of course - they contribute their part. Everyone in the team should be a great developer, this “class” is not about having internal HR in your team).
4. The wizard
Level: Senior+ - staff
The one responsible for most of your design documents. Can be an experienced senior, or staff/architect.
They are usually less hands-on, but can swoop in if needed. The challenge with them is getting them off that wizardry tower :)
They enjoy planning complex solutions, handling scale, and seeing the whole picture. Often they are your external technical interface (similar as the healer might be the ‘business’ interface).
5. The rogue
Level: Junior-senior.
The classic full-stack developer (with maybe some DevOps knowledge).
They are your utility player who can jump between whatever needs to be done. Similar to the tank, they don’t complain - but where a tank’s forte is more about classic implementation of designs, a rogue is more versatile and can do whatever you need.
And we have our team:
Your role in it
One of the challenges of EMs is that they continue doing the things they were good at as a developer. So if you were a ‘warrior’, you’ll have a hard time detaching from the code. If you were a healer, you would focus on people and business (and might neglect hard technical decisions).
I’m a bit rogue and a bit healer. I don’t like implementing a ‘well-known’ plan, but I like to tackle ad hoc problems. Even more, I like to focus on business outcomes.
Your role is to find the gaps, see where your team is weaker. Then, hire for those parts, and help fill them yourself if needed. Common gaps are:
No one to do the shitty, small, and annoying tasks. So EMs ‘clean up’ after their teams so they won’t be distracted.
No healers - product-oriented engineers who are good with people. So EMs spend more time with PMs and stakeholders, and also hold the team together by themselves.
Not enough coding power - that’s a more rare one, but especially in smaller teams, it is expected from us to be able to pitch in when needed.
Build a great team, and you’ll defeat any boss :)
Final words
There is of course no clear ‘division’ between those fictional classes. Everyone is a bit different, and life is not a computer game.
Still, if you try to do this mental exercise with your own team in mind, you might be surprised by what you’ll learn.
I believe that every team member should be good at something and contribute to your ‘dungeon party’.
Discover weekly
The mistakes we’ve made using tools like Cursor and Claude Code and how to avoid them by
. All 6 resonated with me, but mainly number 2, around using Vanilla settings.Reverse imposter syndrome - knowing you are good, but others don’t see it from the outside by
. Another gem, and the first time I heard about this concept.Stop Trying To Make Prioritization “Easy” by
. The anti-patterns of prioritization.
In the end, the real boss isn’t the project, it’s keeping the team alive long enough to finish it.
I feel like I belong to every spec in this analogy 😂