Team leadership is a role that can be a trap for a developer, and can provide huge opportunities for software development

Let's go back two years ago when I was a developer. What was I thinking? “I want to become a team lead. It's cool, he solves all issues, gets more money, they become after the senior . " Then there was no one who would have told me: this is generally about something else. I had to learn from my mistakes.

I became a team lead twice

I have this trait: to try to establish perfect order in everything, to systematize, to build processes. So I've always been drawn to taking on more than just coding. My first startup, let's call it "T", was in total chaos in the development process.



Now I would hardly start working there, but then it was very atmospheric. Just imagine. Many parallel customers. The manager went directly (and pointwise) to the developers. We often missed the announced deadlines and sat up late. I remember how one day the boss called at 20 o'clock and asked him to come to work to tweak the feature for the customer, because "he announced the deadline tomorrow morning." But at T, we were family.







And they did everything themselves - as best they could. I remember putting Ubuntu on a rack server that one of the investors gave us. When I turned it on, it made the sound of a helicopter taking off!



There I grew up to the status of a techdad and worked with a team of 10 people. In fact, the first, intuitively, experience of team leadership happened there.

In D, where I came as a developer, things were different — especially when it came to processes.

The company has implemented classic Scrum: clear sprints, burndown charts, demos, planning, story points, grooming to prepare the future sprint. I was amazed at the quality of the process, wrote the code quietly and watched how everything worked. Then he became friends with the Scrum Master and started throwing questions at him. He eagerly answered and shared cool books.





I especially remember "Scrum and XP: Notes from the Front Line" by Henrik Kniberg. The process in "D" was built close to this methodology: as a result, all management and salespeople knew perfectly well when the result would be.



I also joined Skyeng as a developer. Unlike my other companies, continuous integration is excellently implemented here: every day features are released for production. On my team, the process most closely resembled Kanban.



We had an excellent team lead Petya. On one-on-one calls, we could discuss everything: from problems with not meeting deadlines to task tracker settings. Sometimes I just gave feedback, sometimes I advised something.

So Petya saw through me and learned about the experience of team leadership at T and distance learning Scrum at D.

At some point, he suggested that I hold a stand-up.





Operation "successor" in my case looked like this and took 6 minutes)



And a week later it turned out that a new direction was being opened in the company, and Petya with a part of the team went to that project. The remaining guys need a new lead.

Everything happens by itself, as if the invisible Law of Attraction is pushing you in the direction of team leadership.

When a company needs a team lead and everyone thinks "Where can I get it?", They often take from the guys who:

• better organized
• are quickly involved in team processes and ideas,
• motivated and gaining credibility in the eyes of fellow developers.

Such people are quickly noted in the management, in fact, therefore, when a vacancy appears, they go to them. So it worked for me and at least for several colleagues from other companies with whom I spoke on this topic. And it's funny that everyone noted that the transition did not have to make almost any effort.





But it is one thing to take on the tasks of a team lead, and quite another to cope with them.

What has changed and how I dealt with it

The first few days you live with a feeling of euphoria, triumph and delight. Still: you are at the helm of a whole team, a stake has been made on you, you have more opportunities and responsibility! Several years have passed since leaving T, I gained experience, analyzed my mistakes, saw advanced processes and methodologies and worked on them. All this gave me strength and confidence for the second entry into the team leadership.



However, over time, the feeling of euphoria passed, and everyday life began. Here's what I noticed.



You need to be mentally prepared to part with the "every night Zen" ... and make friends with the "quarterly". The result of a team lead's work is usually not seen in one day or even a week. This is both a plus and a minus.





In his report "Breakdowns and breakdowns during the transition from engineer to team lead" Artem Kalichkin strikes right to the point, saying that "programmers are one of the happiest people in the world."



When you are a developer, every day you have a compiled build, a completed task, a new feature on sale - and there is a certain pleasure in that. A kind of Zen: I have done the job, you can go to rest in the evening with peace of mind.



The team lead rarely has anything to share at the stand-up: because yesterday you “did the planning, was on the phone calls, read the mail and added tasks to the backlog”. Results such as a new section on a website or a big feature in an application are made up of small steps that you and your team go through every day. During this time, you may not write a single line of code, but in general you will drag in such a volume of work that you would never have mastered during this time.



For example, my team made a Study Topics section for the Skyeng app on iOS and Android: we implemented an exercise level map, an energy scale for different categories of students, daily goals, task progress trackers, different mechanics for task cards, voice acting and more.







The same section in the appendix.

This is largely a story about delegation. You need to fight the habit of doing everything yourself. Basically, to become a real team lead, you have to learn how to program with the hands of your team's developers.



An inexperienced team leader can easily become the "bottleneck" of a team . The less the developer is distracted from work, the more ideal the result and the team. Therefore, he has a backlog of tasks with priorities, a stand-up stand, and a couple of other meetings a week. And if you need to plan a new feature for work, a critical bug is found, the prod is down, or the team has a question, they pull the team lead. For everything and everyone to work, you have to communicate a lot.

« -» — , - .

Here I want to say hello and say sincere thanks to my product. Seeing this problem, he sent me to read "Jedi Techniques" by Dorofeev, "Time Management" by Arkhangelsky, as well as study channels and chats for team leads, recordings from conferences, and so on.



The practices I learned helped to eliminate the defocusing. I warned everyone that I would check incoming messages 1-2 times a day, began to arrange days without meetings and calls, planned my working day in writing (I even tried to introduce this practice in the team, but the developers do not like this). I changed my priorities only if something really critical happened. As a result, the things that I had planned were no longer postponed.



In general, I had to break my habits and urgently master a bunch of useful techniques.



The skills required for a lead are not developed during development. As a team lead, you become an active participant in the trade relationship between business and development. The goal of any company is profit, so the customer wants to get many high-quality features from the development in a short time. Developers strive to do quality, but not in a hurry. In this picture, the team leader must keep the right balance between quality, speed and volume of tasks to be solved.



To do this, you must build a trusting relationship with the customer so that he understands what the team is doing, how long it takes to cut a particular feature, whether we have time or not, what to do in order to have time. You need to develop those "soft skills" and at the same time firmly defend the position and principles of the team. And also think about processes, formats, pipeline architecture: how tasks come to you, how they are executed, how they are fixed, how they go to production.



Of course, the skills themselves can be developed. But you need to be prepared that this will lead to a certain transformation of the personality.

No more team lead: how not to lose yourself and find yourself again

Two years ago, I believed that the team lead was the next step in the evolution of a programmer. Now I think that this is another, parallel branch of development. The result of the transition is highly dependent on each individual person - and you will not know until you try.



This role needs to be tested. And not a month, not two. At least six, I think. Even better - a year or two. There is a high probability that it will be difficult, you will want to go back without achieving a result. I would advise you to set yourself a deadline and say: “I do not draw intermediate conclusions until the end of this deadline. I will test it, and in the end I will make a decision, whether it is mine or not. " Personally, I did just that.



After working in the lead position for a year and a half (from September 2018 to February 2020), I consciously decided to leave this role and returned to development. During the same time, the team lead, the channelwhom I read grew up as a CTO in my company.







We are always remote, the main communication is in Slack: so "all moves are recorded." Everything turned out as in the picture: the colleague whom I proposed is trying himself as a team lead, and I am enjoying the "evening zen" in the framework of another team.



And this summer, a couple of other guys who have gone a similar path and I made an internal meetup about our experience. And the most important question that arose among the listeners: ok, how to understand, when you think about where to develop further, the role of the team lead is yours or not?



So the idea came to discuss it in a public format with:

• Egor Tolstoy (Podlodka podcast and courses) - he made a choice in favor of product management and will talk about the moment when he realized that he was tired of the development leadership,
• Vadim Martynov (Kontur and the RndTech community) - he returned to the developers and will tell how he retrained to write code and how all this affected finances,
• and Eugene Kot (Wrike and the same lecture on team lead pains) as moderator.

Everything will take place online next Wednesday (September 2) at 7 pm Moscow / Kiev / Minsk on YouTube: viewers will have a chat and a simple opportunity to turn on by voice. And if you still have the strength, let's talk in the zoom.





Here you can add a reminder to your calendar .



Join the discussion "MoreNeTimlead" or watch it in the recording. I hope our experience will be useful to you, because two years ago I also thought that ...