How to organize team work and let the team leader go on vacation

Are you familiar with the situation: the team leader distributes tasks, does everything himself, but there is never enough time for his professional growth and support of competencies? Without him, nothing is decided in the team, and therefore he becomes a “bottleneck” in the process. Vacation is postponed, because without an irreplaceable leader everything will collapse. This happens for years, and nothing changes.

In this article, I will share an algorithm that I have used in my own practice, how a team leader can get out of the routine and make the team autonomous.

In 2023, I was invited to a large retail company to conduct an Agile transformation. It was necessary to reduce time-to-market (T2M) and adapt teams to changing business goals. I was given five domains to work on, each with an average of five service and five product teams.

In almost all teams, the team lead was appointed by the management. Most often, they were experienced architects or developers. Many of them were not very happy with this appointment, because new responsibilities were added to the old ones. They had to build processes in the team, interact with contractors, teams, and leads from other domains. In addition, new tools for tracking tasks and collecting metrics were added.

As a result, leads began to devote ninety percent of their time to routine tasks and no longer had time to develop the team and themselves. They complained about burnout, constant stress, and working on weekends. Some even gave up vacations so that work would not stand still and the team would complete important tasks faster. During interviews, many leads said that they would not like to play this role in the team, and some thought about quitting from time to time.

After the audit, I applied the following algorithm of actions:

1. Conduct a STATIK workshop

This approach allows for a quick launch of a Kanban system based on the process knowledge gained during the workshop, and also helps with team building. Some teams were newly created, and STATIK helped the participants get acquainted. As a result, the teams created Kanban systems taking into account all the nuances of the process they are working with, wrote down a description of the team (what the team does and does not do), defined the rules by which they will work, and agreed on these rules with stakeholders and contractors.

2. Agree on prioritization rules

We used classes of service as our primary prioritization method.

3. Register DoD and DoR (Definition of Done and Definition of Ready)

At the STATIK workshop, we defined commitment points and readiness points for each team to implement the functionality. We also described the DoD and DoR and agreed on them with the stakeholders. In some cases, we worked out the DoD and DoR for several transitions between process statuses.

4. Establish basic cadences

We selected three mandatory Kanban cadences (Kanban fly-in, flow replenishment, and flow review). We also added regular backlog alignment with stakeholders. For each meeting, we wrote out a plan, timing, goals, and expected outcome.

5. Ensure that all participants in the process are aware of the rules introduced

In each team, we identified stakeholders and mapped them on a stakeholder and influence map. We then held a series of meetings with key customers and stakeholders to agree on new rules and adapt them for teamwork.

6. Conduct a Star map

We conducted a check of the state of each team's competencies and identified bottlenecks where support and development are needed. We developed a plan for developing the most necessary and missing competencies.

7. Conduct master classes on the use of task tracking systems and metrics collection

To ensure that each team member understood how the metrics collection tools work and how to set them up, we held master classes. Each participant tried to set up and get the necessary report or data download themselves.

As a result of these actions, the teams have gained an understanding of the prioritization rules, and now it is clearer to them which request should be taken first into work. This has relieved the team leaders of the burden of assigning tasks to the performer. Now team members sort out the tasks themselves.

Regular meetings with customers have appeared, where requirements and implementation deadlines are clarified. The teams and business have become clear about the criteria for task readiness for implementation and closure, which has allowed the team to have no doubts about what they are taking on and whether it will be accepted by the customer.

The tools for visualization and interaction with the customer and related teams became clear, due to which trust in the team increased, and leads do not have to manually fill out Excel files with task data every week.

Teams began to understand what competencies are necessary for the team to be able to function when risks arise. Unofficial leaders appeared, to whom some of the team leaders' tasks are delegated.

This set of actions is suitable for both product and service teams. It can be applied to different frameworks and already established processes in the team. An important advantage of this approach is that in the shortest possible time the team and customers can better understand and accept the rules of work. The main goal was achieved by reducing uncertainty and understanding the process by the team.

After the new rules were implemented, I asked the team leads again how comfortable they were in their roles. Everyone answered that they were very happy with their role and wanted to continue working in it. And those leads who ignored vacations because of their responsibility for the team were finally able to rest!