Building a Balanced Engineering Team: A 'Dungeon Party' Analogy

While unverified, it's probable that a significant percentage of software engineers have a background in computer gaming. If you're not one of them, this analogy might seem unusual, but the underlying principles are broadly applicable.

This article explores the concept of building an engineering team modeled after a 'dungeon party' from role-playing games. This exercise offers valuable insights for every Engineering Manager, regardless of their familiarity with gaming.

The Challenge of Context in Software Development

Many new AI tools promise increased developer productivity, yet the most significant impediment to shipping software often isn't the act of writing code itself. Instead, it frequently stems from the difficulty in acquiring full context to make sound technical decisions. This leads to common productivity bottlenecks:

• Developers spend over 8 hours weekly searching through Slack, Jira, and Confluence for information.
• Senior engineers receive more than 10 pings a week for answers they've already provided.
• New hires take over 6 months to reach full productivity.

Platforms like Unblocked address this by transforming scattered knowledge from GitHub, Slack, Jira, and Confluence into clear, trustworthy answers. The result is faster onboarding, fewer interruptions, and more autonomous, focused teams.

Imagine you are tasked with assembling a new engineering team under specific requirements:

• The industry or company type is unknown in advance.
• The team must be designed for long-term collaboration, spanning several years.
• The team will consist of five engineers.

How would you structure your ideal team?

Optimizing for 'Damage Per Second' (DPS)

Many companies and Engineering Managers prioritize a 'DPS' (Damage Per Second) approach, aiming to hire the strongest individual engineers and maximize their output.

While this might suit certain scenarios, such as rapidly growing AI startups, I contend that for the vast majority of Engineering Managers, it's a suboptimal strategy, even with an unlimited budget. Highly skilled individuals often seek the most challenging problems and can be difficult to retain and satisfy, as evidenced by talent dynamics in companies like OpenAI and Meta.

Building a Balanced 'Dungeon Party'

Just as every game features diverse races and classes, a typical party relies on at least three fundamental roles:

• The Tank: Absorbs damage, typically with lower offensive output.
• The DPS / Damage Dealer: Primarily responsible for defeating opponents.
• The Healer: Ensures the survival of the party members.

Beyond these, roles like rogues, wizards, archers, and paladins add further strategic depth. Extensive research supports the notion that diverse teams deliver greater impact, exhibit higher satisfaction, and make superior decisions. For example, studies have shown that diverse teams made better decisions 87% of the time, leading to 60% better results.

The most effective engineering teams I've had the privilege to work with consisted of engineers with complementary skills, rather than being homogenous. Let's revisit our initial challenge: building a five-person engineering team designed for years of consistent performance across various circumstances.

(Please note: This is a personal perspective, not a scientific model. It's intended as a fun exercise and a practical framework for analyzing team composition and identifying potential skill gaps.)

The Five Essential Engineering 'Classes'

1. The Warrior

   • Level: Mid-senior to Senior
   • Description: Every team needs an engineer capable of tackling the toughest problems and debugging the most complex issues. This is the individual you rely on for intricate integrations or elusive memory leaks. They genuinely enjoy their craft and thrive on overcoming such challenges. Warriors typically bring experience from previous companies and have a broad understanding of various technical landscapes. The best among them also dedicate significant time to mentoring their peers.

2. The Tank

   • Level: Junior to Mid
   • Description: These engineers excel at receiving clear requirements and executing consistently. Still early in their careers, they have much to learn but are reliable, don't complain, and resist chasing 'shiny objects.' When paired with a Warrior, they can effectively manage the more routine or 'boring' tasks that the Warrior might deprioritize.

3. The Healer

   • Level: Mid-senior
   • Description: An ideal Healer possesses at least two key attributes:
     • Impact-Driven: They prioritize business outcomes, are empathetic, and enjoy engaging with customers.
     • People-Oriented: They are excellent communicators and collaborators, often serving as a confidant for other engineers and generously offering their time. They are the crucial 'glue' that maintains healthy team morale and communication, both internally and externally. (Naturally, every team member, including the Healer, must be a competent developer; this role isn't about integrating an internal HR function into the team.)

4. The Wizard

   • Level: Senior+ to Staff/Architect
   • Description: This individual is primarily responsible for design documents and architectural planning. They might be an experienced senior engineer, a staff engineer, or an architect. While typically less hands-on, they can step in to code when necessary. Their main challenge often lies in remaining engaged with day-to-day implementation. Wizards thrive on planning complex solutions, managing scale, and understanding the broader technical landscape. They frequently serve as the team's external technical interface, much like the Healer acts as the 'business' interface.

5. The Rogue

   • Level: Junior to Senior
   • Description: The classic full-stack developer, potentially with some DevOps expertise. Rogues are utility players who can adapt to whatever task is needed. Similar to the Tank, they are adaptable and don't complain, but where a Tank excels in the consistent implementation of well-defined designs, a Rogue is more versatile, capable of handling a wide range of ad-hoc requirements.

Our Balanced Team Configuration

By integrating these five roles, we form a well-rounded and resilient engineering team.

The Engineering Manager's Role

One common challenge for Engineering Managers is a tendency to continue performing tasks they excelled at as individual contributors. For instance, a 'Warrior' EM might struggle to detach from coding, while a 'Healer' EM might over-focus on people and business aspects, potentially neglecting critical technical decisions. (Personally, I resonate with both the 'Rogue' and 'Healer' archetypes – I prefer tackling ad-hoc problems over implementing well-defined plans, and I strongly focus on business outcomes.)

Your primary role as an EM is to identify skill gaps within your team. Once identified, you should recruit to fill those gaps and, if necessary, personally step in to address them. Common gaps often include:

• Lack of 'grunt work' capacity: No one to handle small, annoying, yet essential tasks, leading EMs to 'clean up' to prevent team distractions.
• Absence of 'Healers': Product-oriented engineers who are also adept with people. In such cases, EMs spend more time with Product Managers and stakeholders, and shoulder the responsibility of team cohesion themselves.
• Insufficient coding power: A less common, but significant, gap, especially in smaller teams, where EMs are expected to contribute code when needed.

Building a strategically balanced team empowers you to overcome any challenge.

Concluding Thoughts

While these 'fictional classes' offer a useful framework, real-world team members are, of course, unique individuals, and life isn't a computer game. Nevertheless, applying this mental exercise to your own team can reveal surprising insights into its dynamics and strengths. The core principle is that every team member should leverage their unique strengths to contribute effectively to your 'dungeon party'.