What does it actually mean to be a project manager? What do you expect a tech lead to do? Does everyone in your organization agree with your definition?
A very common problem that we encounter with our clients is that roles and titles mean different things to different people. This is a troubling not only because it makes it difficult to understand each other, but also because people have disparate takes on what’s expected of them.
We have developed an exercise that helps expose the problem, and gets the team thinking about how they communicate. We call the exercise Roles and Responsibilities.
The exercise
Gather the part of the team that should be involved. Not everyone in the team needs to participate. It’s important to have the key persons there, but too many persons slow things down. 4-6 participants, plus a facilitator should be fine.
List the roles
Now list the roles that your current process uses, and put the roles on the whiteboard. It’s important to keep individuals and roles separate at this point. If you have a tech-lead role and a ScumMaster-role, and they happen to be one person in your team, you should still list two separate roles. Roles that often cause misunderstandings are: project manager, tech lead, architect, test lead, CTO, iteration manager, tracker, Scrum Master and product owner.
List the responsibilities
Next, have the team brainstorm what these roles need to do to fulfil their responsibilities. At this point, it’s just important that it’s something that is done by one of the roles on the whiteboard – which one is not important. What you list should be as hands-on as possible. Things like communicate the architecture, facilitate the retrospectives and send out weekly reports are good items. Listing things like innovate is not helpful. Write the items on stickies, and assemble them in one big group on the whiteboard.
First filtering
When the participants have run out of ideas, it’s time for the next step. You should now have the roles written up on the whiteboard, and one big pile of stickies with things to do by these roles. The facilitator picks one of the stickies, and asks the participants which role the activity goes with. If there is any discussion at all, move it to a “Discuss Later” pile. This first run through is just to get all stuff that everyone agrees on out of the way. After this step – take a minute and reflect on what’s left on the board. This is the root of a lot of the misunderstandings that the team has.
Talk talk talk
What’s left on the board now are the things that the participants don’t agree on. The participants now have to talk and discuss until they discover a way to communicate that is helpful for everyone. Make it clear to them there is no right and wrong – the point is to make explicit what people mean when they talk about the roles, and to make it unequivocal to everyone what’s expected of them.
We’ve used this exercise successfully with a number of clients. It’s by no means a cure-all, but it makes the problem a little more visible. Hopefully it will get the team working on creating a common language and being explicit about what they mean. Good luck!