How to grow from a developer to team lead and live with it further

    My name is Ekaterina, I am a team leader at MoySklad.

    Last year, I spoke at the Saint TeamLead Conf 2018 conference . I collected the main thing from my report in this article, but the presentation itself can be viewed here .

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

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

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


    First of all, I began to control my own working time 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 the Jira, organizational moments;
    • meetings with colleagues who need to plan for the exact time;
    • questions that colleagues come up from time to time.

    In order not to be distracted from work, questions from colleagues need to be spent up to five minutes. Otherwise, it is better to arrange a rally or make a ticket. It is useful to think about this when you are addressing a question to a colleague. Indicate in advance how long you want to tear him from work. Perhaps it will be better for him if you plan a meeting, and he does not have to switch between contexts.

    Another self-management rule came about because of a problem that we call “greedy Shurochka”. 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 many tasks, but we don’t understand which of them will be done in the near future.

    In order not to be 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 appointments in it;
    • I paint the tasks that I plan to accomplish today; I note what hours I will deal with them;
    • as a loader, I leave a little time to resolve minor issues.

    This allows me to clearly understand what tasks I will be able to complete today.

    More responsibility

    Planning your own time is cool, but you can go further and start helping the team leader in organizational matters. So you can declare yourself and understand whether you like such a job.

    For example, you can:

    • carry out stand-ups, retro and planning when the team lead is absent;
    • communicate with partners or customers, if it is customary in your company;
    • answer user questions through support;
    • assist teammates in technical matters;
    • do something else useful for the team.

    Problems and Solutions

    To become a team leader, you need to learn how to analyze team problems and how to solve them. Thanks to this analysis, we have made several useful changes to our process.

    For example, we peeped at the other team's practice of “control points” - they began to break down large tasks into stages, add them to the calendar and daily monitor progress towards achieving mini-goals. If necessary, conduct an analysis and re-plan. So we solved the problem of the discrepancy between the real terms of the tasks and the planned.

    It is also useful to analyze the strengths and weaknesses of your team. If you know them, it will become easier to distribute tasks, because not only gold-developers who work efficiently and on time are not always on the team. Analysis of hard-skills teammates can be done according to the results of the code review, according to tickets in the Jira. Soft-skills is more difficult - you can evaluate them only with constant interaction with the team as part of the 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’s better to pass them on 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 team leader is not always the most skilled person in the team. I think the spirit of competition is not always useful for the team.

    Deputy Search

    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 novice team leader will have to face and that I have encountered is finding a deputy. An ideal development of the event is when the developers, on their own initiative, pick up the duties of team leader. But this is not always the case.

    When I was going on my first vacation, I shared my responsibilities among all the team members - according to their talents and abilities. This 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 doing this.

    As a result, I chose the two most sensible members of the team - the assessment of hard- and soft-skills helped here. One of the teammates was very sociable and with a desire to solve administrative issues, but with weak technical skills. And the second one did the highest quality review in the team and wrote reliable code, but often floated away in analytics, and it was necessary to keep an eye on it.

    On the balance of opposing qualities, these guys were chosen. I asked them if they would like to lead the team a little. I explained to everyone their strengths and weaknesses - so that they looked after each other and restrained in wrong decisions. At the same time, the whole team knew that it was necessary to go to them. We are working with this approach today.

    And some more new problems

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

    But there are many ways to delegate. The simplest thing is to hand out tasks to team members. We rarely do this. More often than not, we try so that the guys themselves can sort out tasks according to their interests.

    But if a colleague understands one issue or another better, forced allocation of tasks can be useful. It happens, and vice versa - a colleague practically does not understand any issue, and I can teach him.

    On the issue of delegation, we went further and introduced into the team the practice of putting the person responsible for a separate task. It works like that. When we are engaged in large tasks in parallel, we divide the team into mini-groups of three to four people. In each group, we select the main one - he will be responsible for the technical part, administrative issues, the organization of meetings with analysts, conducting demo tasks and other matters.

    Thanks to the practice of small team leaders, I can see who and how are doing the tasks. And when necessary, also direct in the right direction. If a person pulls in a mini-group, he will be able to replace the team lead of the whole team if necessary.

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

    Team experiments

    Questions and problems that cannot always be solved quickly fall on the beginner team leader. To understand, it’s useful to read management articles and books. Better yet, consult with older comrades.

    But the experience of others does not always suit you and the team, and universal methods do not exist at all. To understand, you need to try, so I try to implement 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 to improve the process. In retrospect, we discuss the proposed ideas and their implementation, agree on which of them we will take as an experiment for the next sprint;
    • do - during the sprint, the team follows the practices selected 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 has helped to improve processes and achieve results. After we agree on what we will do next: we will leave the practice to a constant, make adjustments to it and repeat, it will refuse at all;
    • act - all selected practices are included in retrospectives, and as a result are included in the list of our best practices.

    All these experiments helped us to introduce the practice of control points, small team leads 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 get bumps. And do not forget to consult with colleagues and delegate tasks.

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

    Also popular now: