Т — техлид

Когда я стал техлидом на одном из прошлых мест работы, это было неожиданно для меня*, но в то же время логично с точки зрения карьерного роста. Мне стало скучно работать в рамках одного проекта, а тут сразу появилась возможность управлять командой разработчиков и несколькими проектами, где я мог реально помочь.

Основная проблема заключалась в том, что если в разработке я ещё как-то развивался (а это хард-скилл, который проще прокачивать), то в лидерстве я в основном полагался на интуицию. Школа менторинга помогла мне упростить взаимодействие с командой. Однако, ретроспективно оценивая тот период, я понимаю, что многое делал не так, как следовало бы. Тогда это казалось нормальным, да и команда (я надеюсь) была довольна. Но, как мы знаем, если что-то кажется нормальным, это ещё не значит, что оно правильное. Всегда полезно посмотреть по сторонам и обсудить опыт с коллегами.

Я всегда говорю техлидам, что одна из важнейших частей их работы — это правильное делегирование и распределение ресурсов. Хорошо, если техлид способен выполнить любую задачу в проекте, но в таком случае зачем нужны разработчики с более низким грейдом? Если лидер берёт на себя всё, это мешает росту команды.

Допустим, мы научились делегировать. Но теперь у нас нет задач. Что делать?

Здесь мы приходим к ключевой роли техлида — созданию технологических вызовов (челленджей), которые помогают улучшать проект. Они могут повышать качество разработки (Developer Experience, DX) и улучшать пользовательский опыт (User Experience, UX).

Когда вы становитесь техлидом проекта, вы фактически отвечаете за всё, что в нём происходит. Это значит, что вам стоит хотя бы в рамках тестовых сценариев использовать свой продукт, собирать обратную связь от пользователей (друзей, знакомых, коллег) и планировать улучшения. Даже если это не напрямую ваша зона ответственности. Быть техлидом — значит не только управлять техническими аспектами, но и развивать проект в целом: и с технической стороны (тех бэклог), и с функциональной (продуктовый бэклог).

Но самое важное — не забирать обычную разработку у команды. Дайте разработчикам возможность расти так же, как когда-то росли вы.