Из senior-разработчика в тимлиды: всегда ли уместен этот карьерный скачок

Всем привет! Меня зовут Паша, около 20 лет я работаю в ИТ-отрасли, 15 из них — в компании «Инфосистемы Джет». Начинал путь с должности лопоухого джуна и дорос до директора департамента разработки. В статье рассказываю, как senior-разработчикам дойти до руководящей позиции и всегда ли уместен этот карьерный скачок.

Начнем с определения

Тимлид — это специалист, который руководит командой, контролирует процесс работы и распределяет зоны ответственности, а также общается с заказчиками и отвечает за конечный результат. Обязанности отличаются в зависимости от особенностей конкретного бизнеса: иногда фокус делается на управление, а где-то руководитель больше вовлекается в процесс разработки и решает «боли» клиентов.

Чем отличаются обязанности тимлида и senior-разработчика

С чего начать свой путь к успеху

«Примерять» роль руководителя начинают специалисты уровня middle, готовые брать на себя ответственность и управление командой. Чтобы определить будущие точки роста, задайте себе несколько вопросов:

1. Что мне будет интереснее в перспективе нескольких лет: общаться с заказчиками и направлять сотрудников или писать код и улучшать hard skills?
2. Есть ли у меня лидерские качества? Смогу ли я найти подход к каждому человеку в команде?
3. Готов ли я отвечать за результат и возможные неудачи?
4. Должность руководителя привлекает меня только из-за финансового интереса или это не главное?

Если вы чувствуете, что позиция тимлида — ваша стезя, прокачивайте soft и hard skills заранее. Можно читать книги, слушать подкасты, проходить многочисленные курсы, посвященные тайм-менеджменту, управлению людьми, планированию и прочим гибким навыкам. Но лучшее решение — взять под свое крыло небольшой проект или кусочек масштабного заказа, чтобы научиться выявлять конечные бизнес-цели заказчиков. Профессиональный и личностный рост всегда идет от новых и сложных вызовов. С другой стороны, вас не бросят в свободное плавание. Старшие коллеги будут наставлять и контролировать все процессы, чтобы заказчик остался доволен.

Так вы сможете попробовать свои управленческие навыки и «прощупать» почву. Если опыт окажется успешным, со временем можно брать на себя больше ответственности, увеличивать количество подчиненных и выбирать более сложные проекты. Дополнительно можно стать ментором для стажеров или junior-специалистов, постепенно увеличивая общую эффективность команды.

Проще дорасти до руководящей должности внутри своей компании. Не все работодатели готовы брать тимлидов «с улицы», так как это несет большие риски для бизнеса. Есть вероятность, что человек не сможет быстро вникнуть в процессы, наладить контакт с коллегами и закрыть доверенный ему проект. Штатному сотруднику будет проще: он уже знает «изнанку» каждого специалиста в его команде, может распределять задачи, основываясь на сильных сторонах.

Мой тернистый путь в разработке

Существует стереотип, что следующая ступень развития senior-разработчика — это обязательно позиция тимлида. Однако на практике это далеко не так. Расскажу на моем примере.

На прошлом месте работы я дорос до должности ведущего разработчика, а также успел поруководить небольшой командой, оказавшись тимлидом «без посвящения». В «Инфосистемы Джет» я попал на позицию middle-разработчика, хотя, казалось бы, мой опыт позволял мне претендовать на «звание» повыше. Но это было объективно. Здесь я начал учиться заново и узнал, что такое грамотно выстроенный процесс разработки, когда ты не просто создаешь решение, которое автоматизирует «какие-то процессы», а докапываешься до истинной проблемы.

При разработке продукта команда должна отталкиваться не только от требований в техническом задании, но и понимать конечные ожидания заказчика и то, как он будет пользоваться разработанным сервисом и использовать артефакты. Если требования и ожидания сходятся, а сотрудники понимают, для закрытия каких бизнес-целей они создают решение, то вероятность успешно закрыть проект и порадовать заказчика будет выше, чем сделать всё по инструкции. Не всегда просто передать контекст существующей проблемы или задачи через один документ. ТЗ может содержать противоречивые или очень общие требования. Лучше вывести представителей заказчика на откровенный разговор, чтобы вывод решения в прод принес необходимый business value.

Вернемся к моей истории. Тимлидом я оказался по воле случая: появилась задача, которую можно было мне доверить. Так я стал руководить командой из двух человек и отвечать за проектирование отдельных кусочков платежной системы крупного сотового оператора.

Мой путь от middle-разработчика до тимлида занял четыре года. Это не много и не мало. Все к этому приходят в разное время. Должно совпасть и личное желание, и необходимые задачи. В какой-то момент я пришел к выводу, что мне стало скучно писать код и намного интереснее раскрывать потенциал других людей, общаться с заказчиками и предлагать им решения для закрытия их потребностей. Сейчас у меня в команде 45 человек. Это разработчики, архитекторы и тимлиды, отвечающие за свои проекты.

Позиция тимлида — не карьерный потолок. Можно стать директором департамента, как я. Или углубиться в профессию ИТ-архитектора, который является тимлидом «на максималках» в команде и хорошим дипломатом в коммуникации с заказчиками.

Когда не нужно переходить в тимлиды

Если вам нравится писать код и не хочется нести ответственность за возможные факапы других сотрудников — не нужно даже пробовать себя в этой роли. В этом случае лучше качать свои hard skills. Стоимости по рынку это не помешает. Senior-разработчики по уровню дохода практически сопоставимы с тимлидами, а степень их ответственности — заметно ниже.

В работе тимлида прежде всего важны личностные качества. Не знать что-то по части стека — не так страшно. Технологии постоянно развиваются, и быть в курсе всего невозможно. Главное, чтобы человек был готов закрывать пробелы в знаниях. А вот без управленческих и коммуникативных навыков ничего не выйдет.

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

Вместо заключения

Переход в тимлиды — не для всех. Каждый выбирает то, что ему наиболее близко. И в этом нет ничего страшного. Например, в свое время я стал руководить человеком, чей стаж превышал мой в три раза. И это устраивало и меня, и его. Я шел качать свои soft skills, а он продолжал совершенствовать свои технические навыки. Важно понять, какой вектор развития подойдет именно вам.