At times, I’ve felt the temptation to equate the development and growth of a team to that of a party in a Role Playing Game. But, while the RPG analogy does have some striking resemblances to real life, it is better for telling us about pitfalls than about actual good practices. They are both similar in that you start out a Role Playing Game with little knowledge of your task, and build a party based on intuition. As the game progresses, you realize that your party design is not exactly aligned to the tasks that you are confronted with.

I played the excellent iOS port of Final Fantasy (the first one) over Christmas, and started my party from a playthrough. The party that was suggested was something I would never have used, myself. It involved using certain classes that were versatile and able to do multiple things, but were not particularly strong in any single skill. I usually pick single-specialty characters with little skill overlap (I don’t play many RPGs these days; my best memories are of Might and Magic 2 and its sequels. Oh, for an iOS port of that).

I used to start off a 4 person party with 2 Warriors, 1 Cleric, and 1 Wizard. What would inevitably happen is that I’d lose one of my pillars: Damage, Healing, or Magic, and then end up with certain tasks that are unnecessarily hard. The lack of redundancy and depth would cause trouble when anyone was incapacitated. The other option is to have several compromise classes – characters that can do various things, but with limits either on their skills progressions or their maximum abilities. That approach would make the game take a very long time as it took forever to do anything, as generally it took members longer to level up.

Because my Wizard had effectively no defense (being a wizard) they would stay at the back of the party. It only look a fierce scowl from an enemy to deal him a grievous blow. Pity the Wizard, indeed…

Life is not an RPG

So the first lesson, as tempting as it might be, is not to view your team as a party in an RPG. This sounds like pretty basic, practical advice that you can use in any situation, but we so often find ourselves talking about ‘The Oracle’ guy, or ‘The UI guy’. This forms a bad feedback loop. We need to describe the members of our team, but words have power. Once you utter that a guys is ‘my middle-tier guy’, the genie is out of the bottle.

On the other hand, you can’t not describe a person, because, like ethos embodied by the RPG party that I tend to create, you have to to be good at something to be great at something. It’s the ‘Jack of all trades’ trap. At the end of the game, my warriors, healer, and wizard were really, really good. There were no compromises, and they could take on any foe.

So as a leader, what should you do?

As a good leader, you need to hold several things in superposition:

• Every team member is an individual and dropping them in a ‘class’ does them a disservice;
• The people you work with outside your team aren’t that interested in the nuances of a person’s skill set. They want to know where a person’s strength lies;
• Saying that a person is ‘good at pretty much everything’ is only helpful if they are the rare person who actually is;
• Sometimes, the members of your team need to be pushed outside of their strengths to improve. No matter how good a database developer you become, you won’t magically become able to deliver a full-stack application if you don’t explore non-database-related skills.

It’s up to you to hold the line

At some point, as a leader, you either build or inherit a team. When you do this, you need to make sure you understand the individuals on it, and their role. They define themselves, and you define the party structure. You are also the party ambassador to the outside world. You are the one that takes their abilities and potential and turns that into a coherent team that can accomplish complex projects. You are also the one who communicates about the members of your team to other teams and higher leadership.

It’s vitally important that a team leader not fall into the pitfall of using RPG-style classes for their team, for the most part. The team is, first and foremost, a group of adult individuals who will eventually resent you pigeonholing them into a simple description. However, when the time comes to promote someone, you do need to identify their core strength and describe them as a paragon of that strength, so that the decision to promote is simple.

In following posts, I’ll talk through sizing and developing teams as they grow from a small core to a larger team, and how I think one should manage the transition from a single small team to a larger team as far as classes and skills depth.

Next: Starting Small