There are two teams that I am involved in HappyFresh. I have been with the first team for over a year now while the other one for about 8 months. One technique that I am using in both teams is the adoption of Role in day-to-day works. So what do I mean by Role? What is the benefit of a Role in a team?
In order to answer the questions above, I will share the way we use the role and its evolution until today.
role as a team building-block
We simply record role expectation in a google doc
The first team I joined is PSN, which focuses on machine learning projects in HappyFresh. As a noobie in this domain, during onboarding, I want to learn about the team process. So I created a google doc and list down the roles in the team. In the beginning, the team had only the Data Scientist Role and the Engineer Role, we record it in a simple google doc. The twist is that we want to be very specific about the expected activity in a role because I am in the learning phase. For example, we wrote Engineer’s accountability to deploy ML model to production and Scientist’s accountability is to researching ML model to use.
The team doesn’t really use any particular project management approach, e.g. sprint from the scrum. We just meet weekly and plan what to start or continue doing. During those meetings, we sometimes discuss our challenges, one day our data scientist shared her challenge in preparing experiment data. Something that an engineer is happy to help. But wait, since we have the document, why don’t we write it down? You know, in case another noobie joins and we can use it to explain the team process. So we write the activity of preparing data in Hive tables as another engineer accountability.
Some weeks, I spent more time on the hiring pipeline, reading CVs, interviewing, and browsing LinkedIn. I share this activity with the team to explain why some of my engineering tasks were overdue. In this case, the activity is so different that it doesn’t make sense to put it in either scientist or engineer. So we create a different role for that, we call it Lead. The document grows with several other roles. We added Operation to monitor our SLO dashboard, product manager to work on the product roadmap.
At this point, a role is a set of expectations set and modified routinely by the team.
Roles are recorded in our JIRA tickets
After a couple of weeks or maybe months recording and evolving roles during our regular team meeting. We feel relieved by our bottleneck and we also feel that our voice, idea, and opinion is heard when improving the team processes and structures. But we don’t really see drastic changes in daily activities because sometimes we forgot about the changes that we have agreed upon. That’s when we start to put the role as an additional label to our Jira ticket. So a ticket of exploring a model for a similar product algorithm becomes a
role-machine-learning-scientist ticket, and adding a caching mechanism to our endpoint ticket has a
Adding a label brings visibility to which role one activity belongs to. And one day, our scientist says, I know it’s not my role but I think I can do it. She asked the engineer to review her work afterward and got some learning from the process. As a manager, I use the label to see the breakdown of our team’s work and learn how complex each part of the project is.
And lastly, it generates one of my favorite moments when someone is asking, hm which role should we label this ticket with? Because it means that: (1) people read and understand the docs. And if we can not find a matching role, that’s great! because (2) we simply add it to the docs and so keep it updated.
As the manager, I sometimes use role labels to analyze the current hotspots in the team capacity. Such data allows me to be more specific on the job description and during the interview phase. Because we know exactly what are roles require more capacity.
Role improves utilization and benefit of existing project management tool and helps the manager in team capacity planning.
Integration with scrum process
The second team is more of a product development team than the first one, requiring more research type of work. I applied the same approach of documenting the evolution of roles within the team, labeling the JIRA ticket with the role name. We also play around with the Jira column.
This team uses scrum from the beginning, so it already has planning, dailies, and retro meeting format. To further gain the benefit of a role in a team, during planning, the role accountabilities clarify a story by forming the definition of done. For example, the developer role has the accountability of writing unit testing and documentation. So when a developer creates a feature, we can expect them to provide those two items. We have recently used roles to break down past sprint velocity data and analyze our team performance during retrospectives sessions. This can be achieved because we label each Jira ticket with the role, and every team task is recorded and updated daily. For example, we know that role system design’s tasks spend more time in the review stage than role developer’s tasks. Turns out this is because the reviewer simply didn’t know about it. So we experiment with different tools for reviewing system design documents.
Role improves existing scrum process
Relying (too much) on teammates
In Happyfresh, we have a slack channel for inter-team communication. This includes requests for support, documentation, and reporting issues. Normally one would simply mention the team name and everyone in that team receive notification for the message. One day, someone from another team request clarification of a feature. Everyone has seen the question, but for some reason, no one actually answers until at the end of the day the requester approach one of our team members personally. She then asks for help in our internal team channel and follows up with the original question after waiting the whole day.
We discussed this scenario on retro, and strangely we all thought that someone else will come and answer. So because the answering question in the inter-team channel is everyone’s responsibility, no one ends up doing it. This is an example of the bystander effect. To avoid such a situation repeat, we create a new Piket role. A schedule is also drafted to appoint one person to be the one in charge for a given day.
Role prevents any work slip away unattended.
Team feedback process
Every 6 or 7 weeks (half a quarter), we start the team feedback process. It started with everyone fills a feedback form for everyone else in the team. The form lists all the roles that he fills. Then, they read comments and feedback from another teammate, retrospect on it, and request further discussion or advice. The feedback is also used by manager and align it with the growth plan that they have created before. For example, a junior engineer fills the developer role and got praised for his improvement in code coverage since the last time. During the same period, he also tries to fill the system design role. He got advice to read more about design patterns to improve the quality of his design.
The manager uses this data during the company performance review so we can objectively say that someone is meeting or exceeding his/her expectation. It is somewhat better than only using feeling. In addition to that, the form shows the performance on a specific per role and activities. So another benefit of a role in a team is that it shows details and reduces the ambiguity that often occurs in deciding performance level.
Role clarifies expectation during performance review and goal setting
Closing – Benefit of role in a team
I hope the short story above has shown some benefits of Role in a team.