Defining a Role with a Retrospective Activity

Agile retrospectives are a widely used practice within engineering teams. They provide teams with a way to reflect on how they work and become better at what they do. One of the main benefits of retrospectives is that they empower teams to define and make changes by analyzing what happened in an iteration and by determining what can be improved moving forward. Here at SoundCloud, we hold retrospectives at the end of every iteration (every two weeks), and we often do them at the end of projects as well.

In this blog post, I’ll share how I used a well-known retrospective activity with my team to define the responsibility of a role.

A few months ago, our iOS Tech Lead took on a new role, which left the team with an open position to fill. Usually, the person in a particular role is the one to define the tasks and expectations of that role as part of a handover. This can be done by writing down what they did and what they were supposed to do, but this process can be somewhat subjective and error-prone.

In this case, because the iOS Tech Lead was involved in many things, some of which weren’t directly related to the team or the platform, there weren’t clear boundaries for the role. That said, both the team and the hiring manager agreed that the definition of the role needed to be updated.

As the Engineering Manager of the Consumer iOS Team, I was asked to come up with a proposal on how to rewrite this role definition together with the iOS Collective. The iOS Collective consists of engineers from the Consumer Team, the Media Streaming Team, and the Core Clients Team. What a great challenge!

I began by asking myself what a good format was for creating a safe space for gathering peoples’ opinions, facilitating discussion, and finding out what the team needed from a Tech Lead. I knew it was important to have the opportunity to bring up new ideas and responsibilities as well, since the team has changed and evolved over time.

I invited everyone from the iOS Collective to come prepared for a one-hour meeting and give me their answers to the following questions:

• What is good in the role, and do you see a value in it?
• Is there something new you want to see in this role?
• Is there something that is being done that you would rather see less of?
• Is there something that is being done that you think would bring more value if it is done more?

This is a modified version of the KALM — Keep, Add, More and Less retrospective format, which is used for having a conversation about current activities and their values as perceived by team members.

For our meeting, we used Post-it Notes to give answers to each of the four questions. Everyone came with their notes, organized by color, and added them to the whiteboard. Since we had a limited amount of time and there were nine of us, each giving around 10 answers for the questions, we knew we couldn’t discuss everything. Instead, we focused on the answers that people did not agree on or that were not clear.

We managed to discuss and clarify the topics that stood out as things people didn’t agree on or were confused about, and we ended up with the following, not counting the duplicates:

• Keep: 26 topics
• Add: 12 topics
• Less: 5 topics
• More: 11 topics

The fact that there were so many responsibilities to be kept and almost the same number to be added and done more justified the need of the role definition. It felt really good to being able to do this important work together and have the assurance that the next Tech Lead would be set up for a good start.

In addition to using this information to define the role of the new Tech Lead, the results were given to the former Tech Lead as feedback on the work they did in that role. It was also a chance to realize what the team was happy with, what was not necessary, what they were missing, and what they wished was done more often.

Using the output of this session, together with the hiring manager and the former Tech Lead, we defined the responsibilities of what is now called the iOS Platform Lead.

Involving the team in the process resulted in a renewed sense of trust, which reinforced morale. It also gave everyone confidence that the new iOS Platform Lead can work in a way that meets the needs of everyone. This is in addition to having well-defined expectations for their role, which is a necessity for performing well and growing.

Roles of the iOS Platform Lead