A rotating Team Lead


At my previous company I set up a rotating Team Lead. This is the basic definition of the role:

## Responsibilities

- Lead the team for the current deliverable.
- Organize the team's work.
- Be a person of contact.

## Deliverables

The Team Lead should have a clear deliverable that they can focus on.

- A deliverable can be technical or product focused.

## Administration

- Organize and run sprints.
- Organize meetings.
- Curate tickets.
- Join weekly sync with other teams.

## Powers

- Make a call on decisions that are deadlocked.

## What it is not​​​​​​​

- Any HR stuff like leave requests or performance review.
- "Boss"
- Hiring stuff.

Below are some of my thoughts after around 2 years of having the rotating role.

Requires buy in from everyone in the team

A rotating Team Lead isn’t going to work unless everyone in the team buys in. The Team Lead doesn’t really have any powers, so it requires the team to get behind the current lead. This often means changing behavior depending on your role. It also requires external members to interface with a different person every time, e.g product people will need to get used to seeing a new face depending on the deliverable.

Gives everyone the opportunity to take responsibility for a goal

Taking ownership of a feature can be a really motivating experience. Being a lead is also a great way to share a feature with the whole team without siloing.

Everyone is able to experience leading a team

I think anyone can learn how to lead. By rotating the Team Lead, everyone will experience what it is like and hopefully get better at it. By making the role transparent, we can also share our experiences on how to improve. This does require some flexibility/empathy as some people are going to be better at leading a team than others. It also means more experienced developers need to be willing to share lead experience with others.

Admin is shared

Admin is often required once you have a few people in a team. By sharing the Team Lead, people get a break from admin. On the flip-side some people may be frustrated or annoyed when leading the team because of the extra admin.

There is a much smaller under the bus factor

This applies to admin but also to features. It makes the team very flexible to different situations like someone leaving the company, or taking long leave etc.

Requires more planning

Extra planning is required to determine who will lead particular deliverables. Deliverables need to be known in advance so that a lead can be chosen. It also requires communication between the current Team Lead and the next, e.g hand-over meetings.

Team lead should delegate some admin tasks

An easy trap for a Team Lead is to find themselves doing a lot of admin and little actual work. This can be alleviated by delegating admin tasks to others in the team.

Choosing a Team Lead

During a planning meeting (e.g roadmap) decide the next Team Lead based on the upcoming deliverables. People can be nominated or self-nominated. If multiple people want to lead the same deliverable, discuss as a team who would be a better choice. If it’s really deadlocked draw straws or flip a coin.

Role should evolve

The role should evolve as the team needs. If some things are not working they should be discussed and the role should be modified. If you do sprint reviews, this is a good item to discuss regularly.