Naming functions and methods are one of the hardest tasks developers need to take. A good name is hard to find, but with enough thought, is useful to show intent.

Likewise, the name for a given role is useful to help establish what that role is accountable for, and can help speed up communication when people have a common understanding of that role.

All models are wrong, but some are useful – George E.P. Box

Unfortunately there are two inherent problems with role titles:

  • People do not understand the role
  • Roles are not the same as people

Issue 1: People do not understand the role

One point of confusion is assumptions about what the role does or does not do. For example, a Project Manager might assume that the QA role will be responsible for a Testing Strategy. In another situation, a different Project Manager might assume the Tech Lead will be responsible for a Testing Strategy. In this case, different expectations could be a source of conflict about which role is responsible for the Testing Strategy.

Another example might be where the Tech Lead assumes the QA role is responsible for the Testing Strategy, and the QA role assumes the Tech Lead is responsible – resulting in no one really thinking about a Testing Strategy.

A great way mechanism to force a way forward is to run a “Roles & Responsibilities” session. I find an effective method to run one is:

  • As an entire team, brainstorm all the important activities that must be completed by the entire group. Ensure that one activity is written on a separate sticky note.
  • Brainstorm some names of roles and put them at the top of a whiteboard/flipchart next to each other. You may want to add a generic “Everyone” or “Team Member” role as well.
  • Ask everyone to place each activity under the roles they think should be responsible for the activity.
  • Walking the board, review each role one at a time and their activities, inviting discussion and disagreement about why the role should be/not be responsible for that particular activity.

This is a very useful exercise for helping to define, and articulate confusion around particular goals.

Issue 2: Roles are not the same as people

Another common failure mode of roles is where people assume that a role is the same as the person. On my business card, I have the title: Generalising Specialist because it’s true – although I consider myself a developer, architect or Principal Consultant, I am also much more than that.

Generalising Specialiast

Generalising Specialiast

People come with a whole bag of skills and experiences that sometimes fit into a particular role. Just as important as it is to understand a person’s strengths – it’s just as important to understand where their fit for a role is and the gaps. A person may be much more capable of playing several roles at once, or a role can be split among a group of people with the right set of skills and experiences.

Concluding thoughts

Remember that roles are a name we give to a collection of responsibilities and it doesn’t necessarily map to single people. A role may be split among people (where the responsibilities are distributed) but it is essential that everyone has the same understanding of who has those responsibilities.