The post has been translated automatically. Original language: Russian
When I became a team leader, I was sure that my main strength was that I was a high-quality developer. That's why I made the first mistake pretty quickly and didn't even realize it was a mistake right away.
We had a project called "The Tribune Award," which was absolutely uncomplicated in the frontline. But there was one really non-trivial part of the logic - we needed a high-quality anti-fraud mechanism for voting without authorization. I looked at the task and thought, "It takes a long time to explain, I'll do it myself faster." It sounded reasonable. I knew the code better than anyone, and deadlines were tight.
By the way, if you are interested in how I technically implemented it in the end, write in the comments, I will tell you in a separate article!
Everything went great for the first few days: I was writing code, the task was moving, and I felt useful. The problems started a little later. The guys came with questions about their projects: how best to arrange the data structure, what to do with the API, how to optimize complex animations. And I answered: "Wait, I'll finish the piece and take a look." Then again: "Let's do it after lunch." Then I delayed the review because I was in the flow and didn't want to be distracted.
After a couple of weeks, it turned out that I had become the bottleneck of the entire production. My project was moving, and the other five people's projects were waiting for my decisions. They weren't standing, BUT if I had the resource, they would have moved much faster in time and would have been made much more technically correct. As a result, the team was formally working during this time, but in fact it was idle. And the most unpleasant thing was that only I understood the difficult parts of my project. If the bus factor had happened, no one would even have been able to pick up my project!
Then I realized a simple thing.: A team leader's speed is measured not by how much code he has written, but by how fast the whole team is moving. My five hours spent explaining the task saves the team dozens of hours of waiting.
What I changed after that:
- I no longer take on tasks from a critical project path. If something is complicated, I sort it out with the developer and help design the solution, but he writes the code.
- The team's questions and reviews are now more important to me than my own code. If someone is waiting for my reply, it's a blocker, and he goes first.
- I only write code that doesn't block anyone: prototypes, tools, experiments.
It was unpleasant to give up the role of "the strongest developer in the team." But a team where several people can solve complex tasks ends up working faster than a team where they are solved by one team leader.
And what was your first mistake as a leader?
Когда я стал тимлидом, я был уверен, что моя главная сильная сторона - что я качественный разработчик. Поэтому первую ошибку я совершил довольно быстро и даже не сразу осознал, что это ошибка.
У нас был проект "Премия Трибуны", который в фронтовой части был абсолютно несложный. Но в логике была одна по-настоящему нетривиальная часть - нужен был качественный механизм антифрода для голосования без авторизации. Я посмотрел на задачу и подумал: «Объяснять долго, быстрее сделаю сам». Звучало разумно. Я знал код лучше всех, а сроки поджимали.
Кстати, если вам интересно, как в итоге технически я это реализовал, пишите в комментарии, расскажу отдельной статьей!
Первые дни всё шло отлично: я писал код, задача двигалась, я чувствовал себя полезным. Проблемы начались чуть позже. Ребята приходили с вопросами по своим проектам: как лучше устроить структуру данных, что делать с API, как оптимизировать сложные анимации. А я отвечал: «Подожди, сейчас доделаю кусок и посмотрю». Потом снова: «Давай после обеда». Потом я задерживал ревью, потому что был в потоке и не хотел отвлекаться.
Через пару недель оказалось, что я стал узким горлышком всего продакшна. Мой проект двигался, а остальные проекты пяти человек ждали моих решений. Они не стояли, НО если бы у меня был ресурс, двигались гораздо быстрее по времени и были бы сделаны гораздо правильнее технически. В итоге это время команда формально работала, но по факту простаивала. А самое неприятное - сложные части моего проекта понимал только я. Если бы случился bus-фактор, никто бы даже не смог подхватить мой проект!
Тогда я понял простую вещь: скорость тимлида измеряется не тем, сколько кода он написал, а тем, насколько быстро движется вся команда. Мои пять часов, потраченные на объяснение задачи, экономят команде десятки часов ожидания.
Что я изменил после этого:
- Я больше не беру себе задачи с критического пути проекта. Если что-то сложное, я разбираю это вместе с разработчиком, помогаю спроектировать решение, но код пишет он.
- Вопросы и ревью команды для меня теперь важнее собственного кода. Если кто-то ждёт моего ответа, это блокер, и он идёт первым.
- Я пишу только такой код, который никого не блокирует: прототипы, инструменты, эксперименты.
Отказаться от роли «самого сильного разработчика в команде» было неприятно. Но команда, где сложные задачи умеют решать несколько человек, в итоге работает быстрее, чем команда, где их решает один тимлид.
А какой была ваша первая ошибка в роли руководителя?
Share
