How to grow from a developer to a tmlid and live with it further

My name is Ekaterina, I am a Timlid in the company of Moysklad.

Last year I spoke at the conference Saint TeamLead Conf 2018 . The main thing from her report gathered in this article, the very same speech can be viewed on the link .

My path to the company as a developer began two and a half years ago. Then there were no established processes in My Store, and our team leader was appointed according to the principle “Is this the most experienced developer in the team? You will be the team leader. ” But a good developer is not always a good team leader.

As if there was no responsible person in the team, we preferred to think that we have a democracy. But if there is no responsible, the processes in the team begin to fall apart.

At some point I wanted more control and productivity for myself. Probably, then I thought for the first time that I could become a team leader.

Self management

First of all, I began to control my own working hours and tasks. I divided the questions that came to me during the day into three types:

• tasks that can be timed and prioritized. These are tickets in Djir, organizational moments;
• meetings with colleagues that need to be planned at the exact time;
• questions that colleagues approach from time to time.

In order not to be distracted from work, you need to spend up to five minutes on questions from colleagues. Otherwise, it is better to agree on a rally or make a ticket. This is useful to think about when you contact a colleague with a question. Indicate in advance how long you want to take him away from business. It may be better for him if you schedule a meeting and he does not have to switch between contexts.

Another rule of self-management appeared because of the problem that we call the “greedy Shura”. So we are talking about colleagues who take a lot of tickets and do not have time to do them. It turns out that a person has a lot of tasks, but we do not understand that of them in work will be done in the near future.

In order not to be a greedy Shurochka, I devote five minutes of daily time to planning a to-do list for the day. During this time, I:

• I look through the calendar and record meetings in it;
• I schedule tasks that I plan to perform today; I note what time I will deal with them;
• As a loader factor, I leave some time for solving minor issues.

This allows me to clearly understand what tasks I have time to complete today.

More responsibility

Planning your own time is great, but you can go ahead and start helping the team leader in organizational matters. So you can express yourself and understand whether you like this job.

For example, you can:

• hold stand-ups, retro and planning when there is no timlid;
• communicate with partners or customers, if your company does so;
• answer user questions through support;
• help teammates with technical issues;
• do something else useful for the team.

Problems and Solutions

To become a team leader, you need to learn how to analyze the problems of teams and their solutions. Thanks to this analysis, we have made several useful changes to our process.

For example, they peeped at the other team from the practice of “control points” - they began to break up large tasks into stages, add to the calendar and daily monitor progress towards achieving mini-goals. If necessary, carry out analysis and rescheduling. So we solved the problem of discrepancies between the actual deadlines for the tasks and the planned ones.

It is also useful to analyze the strengths and weaknesses of your team. If you know them, it will be easier to distribute tasks, because not always there are only gold developers in the team who work efficiently and on time. Hard-skills analysis of teammates can be done by reviewing the code, by tickets in Djir. Soft skills are more difficult - they can be assessed only with constant interaction with the team within the framework of tasks.

When you become a team leader, you have to put up with reality - you do not always have time to do some tasks, and sometimes you just can’t master them. Then it is better to transfer them to senior developers. No need to try to control everything and compete with colleagues who are stronger than you. You just need to accept that such people can be, and the team is not always the most skilled person in the team. I think the spirit of rivalry is not always useful for the team.

Search for Deputy

Becoming a team leader is very cool. But with this new problems, responsibilities and greater responsibility come to you.

One of the first problems that a newbie tmilid will have to face and that I have encountered is the search for a substitute. An ideal variant of the development of an event is when developers, on their own initiative, pick up duties of the team leader. But this is not always the case.

When I was going on my first vacation, I divided my responsibilities among all team members according to talents and abilities. It did not work. Colleagues did not understand to whom and with what question to go, as a result they came to me. I do not advise to do so.

In the end, I chose two of the most intelligent team members - this was where the hard and soft skills helped. One of the teammates was very sociable and with a desire to solve administrative issues, but with weak techs. And the second did the highest quality review in the team and wrote a reliable code, but often swam away to the analyst, and he had to be looked after.

On the balance of opposing qualities, these guys were chosen. I asked them if they wanted to guide the team a little. Each explained their strengths and weaknesses - that they looked at each other and restrained in the wrong decisions. In this case, the whole team knew that it was necessary to go to them. With this approach, we are working today.

And some more problems

When I became the team leader, the whole team started contacting me at once. Various administrative tasks, rallies, and questions about this appeared. It was necessary to figure out how to work with it and not fall into an existential crisis. The answer turned out to be simple: be patient or delegate.

But you can delegate differently. The simplest thing is to distribute tasks to team members. So we rarely do. More often we try to make the guys sort out the tasks according to their interests.

But if a colleague understands this or that issue better, the forced distribution of tasks can be useful. It happens and vice versa - a colleague practically does not understand any question, and I can teach him.

In the issue of delegation, we went further and introduced the practice of putting a person in charge of a separate task into the team. It works like this. When we are engaged in large tasks in parallel, we divide the team into mini-groups of three or four people. In each group we choose the main thing - he will be responsible for the technical part, administrative issues, organizing meetings with analysts, carrying out demo tasks and other matters.

Thanks to the practice of small tmlidov I can see who and how to cope with the tasks. And when required, also send in the right direction. If a person pulls in a mini-group, he will be able to replace the team leader of the team if necessary.

This method helps me not to drive myself into an administrative routine, sitting at the tenth meeting.

Team experiments

On the new team leader questions and tasks are dumped, which cannot always be solved quickly. To understand, it is useful to read articles and books on management issues. And even better - to consult with older comrades.

But the experience of others does not always suit you and the team, and there are no universal ways at all. To understand, you have to try, so I try to introduce new practices using the Deming cycle, adapted to the team. Here's how it works:

• plan - during the sprint, each team member can make a proposal for improving the process. In retrospect, we discuss the proposed ideas and their implementation, agree on which ones we will take as an experiment for the next sprint;
• do - during the sprint, the team follows the practices chosen in retrospect;
• check - in retrospect, we discuss the results of the experiment. Each team member gives feedback, we analyze whether the implementation of the practice helped to improve the processes and achieve results. After agreeing on how to proceed: we will leave the practice on a permanent basis, make adjustments to it and repeat, refuse completely;
• act - all selected practices are entered into retrospectives, and as a result are included in our list of best practices.

All these experiments helped us to implement the practice of control points, small timlids and many more useful things.

For myself, I understood the main thing: if you want to organize a team, start with yourself; Do not be afraid to gain experience and fill cones. And do not forget to consult with colleagues and delegate tasks.

If you have questions, ask them in the comments. Or maybe you have your own ideas on how to become a team leader, let's discuss :)