Team leading: the art of becoming expendable

#leadership #management #teamwork #anygivesprint

What does being a team lead means?

The answer to that question is in Al Pacino's speech from the movie "Any given Sunday". A good team lead is the one that is able to instill that message into every team. So the next question is: How do you do it? That is the hard part.

There are four different fronts any team lead has to deal with and take care of:

the team lead himself / herself
the teammates
the project
the client

Let's try to go into detail for every one of them.

The team lead himself

Every team lead's main goal should consist on being expendable, if the work is properly done a time will come when the team is a cohesive and autonomous entity that will no longer need any guidance.
That means that your primary job is to actually building the team. Once an actual team is in place and properly running, then it is going to be just maintenance stuff. When even maintenance is no longer needed the team lead becomes finally expendable as much as any other teammate, there is no place for individuals, there is place only for the team.

A team varies in size, seniority, roles and adapts to different types of projects and technologies. There may be cases in which the team has a fair amount of senior devs, others in which there will be no project manager or product owner, some scenarios will lack a proper requirements definition whereas in some others it will be hard to deal with the client.
For all these reasons a team lead should be a jack of all trades adapting himself to every situation in order to play a lot of different roles at the same time: tech lead, architect, project manager, product owner, senior, mentor, etc.
In the end all this can be resumed by being an unblocker. Being ready to jump on any issue, fire, meeting, chat, pairing session, and so on.

Note that being always there ready to unblock others implies that the team lead should not be blocked at any time and should carefully decide when and by what he is going to be blocked (we will get to that later). At the same time the probabilities to have some teammate blocked should be kept at a minimum and the easy way to do that is "keeping your house clean": both the backlog and the sprint boards should be tidy and up to date. Requirements, acceptance criteria and documentation should be clear and properly maintained. The same goes for the code and any tech and non-tech piece of the project.

The teammates

As stated before the main goal for a team lead is to be expendable reaching a situation in which the team is completely autonomous and able to work like a clockwork.
The most important tool for that is a set of team agreements. Team agreements are common practices defined and maintained by the team itself. They are alive and continuously changing according to the team needs. Usually they address a set of different aspects of the team day to day work like:

Communication: regardless of the tool you are using, it is important to keep conversations as much open and public as possible so every stakeholder can be always aware of what is going on. Communication with the client must be direct and transparent. In the end, the good outcome of every relationship is related to the proper set up of expectations and that can only be achieved by the correct communication approach.
Code management: obviously the tech part is important and, for that, a lot of different things must be agreed upon before jumping into the actual implementation, such as:
- Naming conventions.
- Repos and branches management.
- Pull request handling.
- Delivery practices (CI/CD setup and usage).
- Testing.
- etc.
Agile (or not) workflow: finally there is agile and its related ceremonies bit. It is important to define how to deal with:
- Backlog and boards.
- Tickets: description, acceptance criteria, estimation
- Definition of done.
- Sprint plannings and demos.

The above ones are just some examples of possible team agreement bits but keep in mind that any team should come up with their own ones and every team member should be the keeper of those agreements taking care of having them respected, updated and useful.

Apart from team agreements, bear in mind that a team is made of people, and a team lead's most important task is to motivate them, making them happy to work on the project. In order to achieve this it is important to get to know them, their sweet and weak spots both from a tech and non tech perspective. The idea is to know how to empower them and make them grow defining a path to follow. As already stated transparency and expectations are the key, one on one meetings are an amazing tool that can help the team lead to better know his teammates, their issues, frustrations, ideas, desires, and so on, basically a way to take their temperature and, by doing that, the whole project temperature.

Finally, note that it is not only about the relationship between the team lead and his teammate but also between the different team members. Fostering the relationship between teammates is also part of the job, promoting code review and pairing sessions is one of the ways, and from a non tech perspective there are virtual (or not) coffee sessions, team building events and so on.

The project

The ultimate goal of every team is to have the project running smoothly and being delivered on time.
For a team lead it is like having to manage a plane, he has to make it go from point A to point B. There will be turbulence for sure but the crew is there and with teamwork the mission will be accomplished.
As with any plane, the higher is the level of control the crew has, the more likely is to have a safe trip. That is why the following bits are important and need to be taken care of:

Monitoring: it is impossible to fly without a proper instrumentation monitoring capability, the project (the platform), independently of the technology, is going to be deployed somewhere, it is going to rely on different pieces of infrastructure and it is going to be used by a given amount of users. It is essential to have monitoring dashboards and alerts in place that are able to deal with data related to:
- infrastructure pieces usage (memory, cpu, etc.).
- inbound and outbound requests (synchronous and asynchronous ones).
- business logic related workflows.
- etc.
Documents and diagrams: knowing from the start what the team is aiming for and clearly defining which are the basis of the project is a must. There should be no room for ambiguity hence it is good to plan ahead and define everything, a good drawing or document is better than one hundred meetings. Examples of useful documents are:
- architecture diagram: where is every piece of the project located and how it interacts with the others.
- entity model diagram: it does not matter whether you are dealing with relational or non-relational storages. Knowing the entities the team has to deal with is a must.
- interfaces definition: documenting both synchronous and asynchronous interfaces will remove any possible misunderstanding related to code implementation.
Testing: having in place a shared testing practice will allow the team to build its own security net and speed up any future change implementation. Moreover the tests suite will act as a documentation explaining what the code is supposed to do in a more human readable way.

All the above bits and many more will help the team lead becoming expendable. If everything is well monitored, documented and tested every teammate can be expendable and any new joiner will have a smooth and quick ramp up.

Now let's go back to blocking tasks and how the team lead should avoid them as much as possible.
In any project a good task distribution is crucial. How the tasks are assigned will impact directly on the delivery speed and, most important on team members skills development and improvement.
The best way to improve a developer skills set is to make him face tasks whose difficulty is slightly above the developer capabilities. A task too easy for him will result in a lack of motivation, a task too difficult for him will result in frustration. That leaves the team lead dealing with the following two types of tasks:

too easy ones that no teammate will learn from.
too difficult ones that may block and frustrate the teammates.

The first are the ones that the team lead has to take care of. The second are the ones that the team lead has to properly divide into smaller ones and assign to the teammates and most important follow closely and make sure they are properly done. The process of dividing and conquer a huge task is a great learning opportunity for any team member since it involves:

planning.
documentation.
risk assessment.
follow up plan.
etc.

It is a good learning exercise that can be done in pairing sessions that will again result in having somebody else growing and ready to deal alone with the next big tasks (adding up to the team lead expendability goal).
Again the team lead needs to be unblocked at all times in order to be ready to give this kind of guidance to the team and, as we will see in the next section, to offer his knowledge and guidance to the client as well.

The client

The client will naturally look at the team lead as the guy to go for and ask things to. That is something that will work out properly in the initial project phases but should not last in the long term. Communication again will do the trick.

Being open and transparent is the main thing to strive for. The development team and the client should be as much aligned as possible and they should learn how to speak the same language. Expectations again need to be properly defined.
Speaking the same language means having the client understanding in detail what the team is doing:

It is worth spending some time explaining to the client how the architecture is set up and how all the different infrastructure pieces interact (architecture diagram to the rescue).
It is essential to explain to the client how the synchronous and asynchronous interfaces are defined (sync and async documentation is a must).
The client must be able to understand how the platform works and even how to interact with it:
- Some handy backoffice endpoints will do the trick.
- Access to the monitoring dashboards and alert system will help as well.

Note that if all the above points are taken into account, the amount of requests, doubts and questions that the client will raise to the team lead will drastically be reduced, the client will have the tools to solve his own questions without even asking them.

On top of that, keep in mind that the goal is to be expendable. Once again, the team lead should stop being the go-to person as soon as possible. That can be achieved by keeping the team structure as lean as possible. Being the team lead does not mean being the dictator, actually it is quite the opposite. Working in the shadows is the way to empower team members. Anytime the client raises a question, the team lead should be ready to push the correct teammate to answer it. That team member will learn how to deal with the client and the client will learn that everybody (the whole team) is capable of answering questions.

Conclusions

It may sound strange but in the end it is all about building a legacy, a shared one created and maintained by the whole team. Doing things in the proper way and ensuring that things will be done properly until the end, of the sprint, of the project, of the company.
Remember that projects will end, clients will come and go, companies will fall and rise, and all we have left are the human relationships we managed to create. If you work as a team lead, be good to yourself and be more than good with your teammates, that is all that matters.