Прежде чем вырасти до своей первой позиции тимлида, я был разработчиком. В небольшом стартапе мы делали интересный продукт, у нас был молодой активный коллектив, понимающее руководство. На этой благодатной почве я прошёл карьерный трек от стажёра до старшего бэкенд-разработчика. Потом мне определили на менторство моего первого джуниора, и я получил предложение стать тимлидом. Сразу скажу, что мне всегда хотелось расти, создавать большие классные проекты. Так что возможность стать тимлидом я воспринял с удовольствием. Потом я поработал тимлидом в крупной компании — дочке Сбера, и год назад оказался в перспективном и интересном стартапе, где уже вырос до технического директора.
Оглядываясь назад, я понимаю, что в моем треке были нюансы, к которым я готов не был. Не знаю, насколько возможно к ним подготовиться в принципе, но я решил поделиться. Если вы сейчас принимаете решение о том, соглашаться ли вам на позицию тимлида, это может быть полезно.
1. Резкого роста дохода не будет
Разумеется, условия по новой должности нужно обсуждать с эйчаром или руководителем, который предлагает эту новую должность, как говорится, «на берегу». Однако, рынок таков, что тимлид на старте редко получает больше синьор-разработчика, а иногда и меньше. И до того, как ты сможешь претендовать как управленец на другую зарплату, может пройти немало времени. Если думать, что тебе кто-то резко поднимет ставку вдвое после бурных аплодисментов на перфоманс ревью через полгода, то рекомендую снять розовые очки — это вряд ли произойдет. Фактически ты переходишь на совсем новую позицию и функционал, в котором ещё не разбираешься, и свою результативность предстоит доказать. На рост дохода можно рассчитывать, в зависимости от конкретного трека и компании, спустя полтора-два года. Если перейти в другую компанию, можно ускорить процесс, но, я думаю, минимум год на это всё равно уйдет.
2. Ты больше не будешь самым умным в команде
Это больно для тех, кто прошел путь от стажера к синьору, и считает себя крутым разработчиком — именно такие чаще всего переходят на должность тимлида. Ты всегда стремился быть первым, лучшим в своей профессии, а теперь надо перестроиться, потому что ты уже точно не будешь первым и лучшим. Однако другого пути нет — когда становишься тимлидом, переключаешься с технической работы на управленческую, а техскиллы уходят на второй план. Рано или поздно в команде начнут появляться люди, которые будут подкованы лучше тебя. Я не знаю, можно ли к этому быть готовым, но пережить это обязательно придётся.
3. Будешь меньше знать о своём же проекте
По сути это вытекает из предыдущего пункта: когда меньше работаешь с кодом, постепенно начинаешь хуже знать свой проект с технической точки зрения. Это нормально, особенно когда проект сложный, и компания растет, и команда растет — всё знать просто нереально. Вроде бы это понятно, но все равно, когда переходишь в новую роль и начинаешь меньше писать код, меньше его трогаешь руками, однажды замечаешь, что не можешь сходу ответить на какой-то вопрос о том, как что устроено. Да, у тебя есть команда, у которой можно спросить — а здесь как, а тут что? Но раньше ты все ответы знал сходу сам. Так что первое время в новой роли может быть сильно некомфортно — по инерции может казаться, что ты не владеешь ситуацией, то есть, недостаточно хорош. Это тоже больше кейс для разбора с психологом и работы над собой. От себя могу посоветовать сразу постараться ориентироваться на новые стратегические цели. Можно опираться на мнение руководителя или основателя бизнеса, просто спросить у него: как ты меня будешь оценивать? Вряд ли он скажет, что нужно разбираться в коде лучше всех, скорей всего там будет перфоманс команды, удержание ключевых сотрудников, сроки закрытия задач, количество багов, стабильность системы.
4. Придётся много общаться с людьми
Программирование и управление командой программистов — диаметрально противоположные занятия. Разработчики — это по большей части интроверты, которые любят поглубже закопаться в код, и чтобы их не трогали. К сожалению, на позиции тимлида закопаться не получится. Придется постоянно общаться с людьми: коммуницировать с другими подразделениями, принимать и распределять задачи, общаться с командой и отслеживать настроение всех её членов, их результативность, проблемы. Это и есть работа тимлида. Нужно проводить регулярные one-2-one встречи с каждым из сотрудников, формулировать грамотный фидбэк, спрашивать, как человеку работается вообще. Недостаток общения с членами команды может выйти боком тимлиду, например когда один из разработчиков увольняется одним днем, и при расставании ты узнаешь, что оказывается он очень выгорел. И наоборот, хорошо замотивированные сотрудники, которые знают, что делают и как оценивается их работа, могут существенно повлиять на скорость и качество релизов.
5. Придётся забыть о состоянии потока
То, чего мне на должности руководителя на самом деле не хватает. Разработчикам это состояние хорошо знакомо: фокусируешься, входишь в поток и можешь за час сделать всю работу за день. Состояние потока и в разработке поймать иногда непросто, а на должности тимлида можно о нём забыть. Контекст и фокус внимания постоянно меняется, ты должен быть всегда на связи и со своим руководством, и с подчинёнными. И всем от тебя непременно что-то нужно. Причем количество тех, кто будет тебя дергать со всех сторон, всегда будет расти — вместе с тобой и проектом. К этому нужно быть готовым. Расфокусировка, особенно поначалу, первые полгода-год, будет существенной. Спустя несколько месяцев появится понимание, как управлять этим, наработается навык защиты собственного времени. Так, если у меня есть задача, которую нужно сделать в фокусе, я выделяю конкретное время, предупреждаю, что меня не будет на связи, отключаю все уведомления и погружаюсь в задачу. Но, честно говоря, происходит это редко.
И что же, отказываться от роста?
Конечно, ни одна из этих причин не может стать препятствием, когда ты нацелен на рост. Можно, безусловно, расти и просто в техническую сторону — заниматься архитектурой больших проектов, стать техлидом. Для меня ветка управления коллективом оказалась более интересной, и сегодня я рад, что пошёл по этому пути. Всегда хотел делать большие классные продукты. В одиночку это уже невозможно, нужна команда, а команде — лидер.
И ещё один нюанс: если думать в сторону создания своего продукта, стартапа, то опыт руководящей работы, тем более в стартапе, — просто мастхэв. Учиться управлять людьми и проектами сразу в собственном бизнесе будет в разы сложней, а цена ошибки гораздо выше.
