What's in a role title?

Two Lego Batmen side by side. Credit to Stick Kim https://www.flickr.com/photos/stickkim/

More often than not projects start with a hastily assembled crew of people, all from different backgrounds, each with their own experience. Someone will have put together that team based on the roles they think are needed to do the work. A product manager, a delivery lead. A user researcher, maybe a service designer. Throw in an interaction designer, a content designer and a few devs. Job’s a good’n?

Once those people start working together, you hope they get through their forming and storming quickly, so that they can start working well together.

The problem with role titles

Role titles are inventions. We imagine a bundle of skills that someone might have, we imagine a person with those particular skills, and we come up with a title to summarise what that person does. 

It would make it so easy to just assemble teams that have a predictable set of skills to do the job. Each person with a role title being exactly the same. The problem with this is that people rarely fit neatly into a specific role. We aren't minifig-like copies of each other.

First of all, there are always trade offs when you put a team together. You might not have the budget to buy a square peg for each of the square holes you have. Or you might not have enough pegs of the same shape. You inevitably have to put together the best team that you can, and that involves compromise.

But more importantly, we’re talking about people. Not pegs, or  - shudder - resources. People bring with them a whole breadth of experiences, preferences and strengths. For example, some delivery managers love to focus on a team’s process above everything else. Others care more about facilitating discussion and building consensus, or focusing on the wellbeing of the team. And every delivery manager / product manager pairing has to figure out their respective strengths and weaknesses.   

Prioritise skills

Relying solely on people’s role titles is rarely a predictable or consistent indicator that you’ll have the perfect mix of skills you need for the job at hand. Role titles can be useful (if nothing else, the Government DDAT Capability Framework gives a sense of what others may expect of a certain role), but when assembling teams we need to be careful about assuming that we just need 3x developers, 1x delivery manager, 1x user researcher, 1x product manager etc.

The same applies with qualifications, which aim to standardise skills and experience. All too often they can become a shorthand for a certain type of person, and we can lose sight of whether they have the skills or experience needed for the role. Depending on your perspective around Scrum, you might have a bias for or against someone who describes themselves as a certified scrum master or a Prince 2 practitioner. You might see these labels as a red flag or a mark of quality. 

We need to think about the nature of the work - what is the main goal, what is the main emphasis, what sort of things do we need to major on? Most importantly, what skills do we need to have in the team to get that done? Thinking about the skills you need can give you more flexibility on assembling the right team. Some Interaction Designers have content design experience. Some Service Designers have product management skills. Some Developers can do a bit of technical architecture. 

This is why I really liked the ODI’s Data Skills Framework. It doesn’t describe a particular role, but shows clusters of different skills. You can choose your own adventure, depending on the nature of your work, interests or experience. 

Work out what you need from each other 

Once you have assembled a team of people with the right skills, get everyone in the team to work out what they each need from one another. One really effective way to do this is to run a session around ‘What I need from you’.

It gives the team the opportunity to express what they need from each other member of the team, and it gives space to a better discussion about the overlaps between people.

Giving a team the space to work through these questions isn’t a sign that your team was broken to begin with. It’s part of the process.