Balance your team skills RPG style

All developers¹ feel they are “above average”.
That can’t be true, right?
Or maybe it can?

Well, depends on how you measure.
A while ago I recruited a new team, and in this post I want to share some of my newly acquired insights.

The analogy

Remember those role playing games of the nineties? You had to form a party of heroes for a quest. Where for each chosen character, you could also adjust their stats. Strengthening some of the character’s attributes at the expance of other attributes.

pool of radiance - ruins of myth drannor: character creation; assign ability scores screen

It was not a good strategy to have all your heroes optimize for the same attribute. Enhancing only strength, for example, and neglecting wisdom, dexterity, etc’… would not get you far in the game.

pool of radiance - ruins of myth drannor: character creation; select party screen

It’s also a bad strategy to average all your characters on all attributes, making them mediocre at everything. Diversity was key to advance in these games.

Same goes for engineering teams.
Some people have more of a “hacker mindset”, some are “builders”, other “menders”, or “enablers”, and so on…

And like in these games, where some missions can only be passed with a combination of (for example):
Characters that are very strong and specializes in melee attacks, together with characters that are agile & accurate and specializes in range attacks. We need to assemble an engineering team with different types of “experts”. And much like the games, not all expertises are essential to all tasks.

Optimize your team for the job at hand

When building a new team, ask yourself questions like:
Does the goal leans more towards exploration, where fast feedback & market validation are key to success? Or more towards long term stability and maintainability in a well established product?

Obviously, the perfect team for the job would look different based on the goal. If I want to explore, release POCs, demos and experiment fast, I would lean more towards a “hacker mindset” team that works in a “quick & dirty” style (hopefully more quick than dirty). If the team’s task is to maintain a viable product, then “doing things right” becomes a much more desireable mindset than “quick & dirty” (which is probably even harmful in such scenarios).

You may (probably) still want a “hacker” on your “maintaining a legacy product” team, or a “maintainer” on your “hacking a POC” team, as no task is ever “pure”. Much like in these games, more often than not, you’ll need to asign tasks to the appropriate “expert”. So make sure you got one on your team.

The “like-minded” trap; or how to diversify?

It’s very easy, when building a new team, to favor people that “think” like us. This is a hard one: how to identify the skills & strengths we lack (and need) in candidates? I don’t have the answer, and sometimes I only notice my blindspots post-mortem. Best I can advise is: do your homework! Be explicit on the teams goals. Try to identify the skills needed (& currently lacking). Then, Optimize for those.

Most people are “above average”

It may have sounded a paradoxal claim when you first started reading this post. But it’s true. Most people ARE above average, just not in everything. Some people are better at hacking stuff - à la “move fast and break things”, others might be methodical & thorough, perhaps working TDD style. We all have our strengths and weaknesses. If you focus on people’s strengths, you’ll soon find out that indeed, there is no paradox.

---

1. Sure seems so. I never met anyone admitting they’re “below average”↩︎