Больше 200 плюсов в конце 2024 года собрала на Хабре статья с прямолинейным названием «Не надо быть тимлидом», и этого хватило, чтобы страх про «карьерную ловушку» пошел гулять по чатам и каналам. Теперь у этого тезиса появился содержательный оппонент: карьера тимлида, как утверждает Евгений Антонов, это не тупик, а точка развилки, после которой вариантов у сильного специалиста становится скорее больше, чем меньше.
В докладе на Saint TeamLead Conf 2025 в Петербурге, о котором сообщает Habr / Карьера, Антонов разбирает самую неприятную для роли тимлида репутацию по косточкам. У автора для этого неплохая оптика: 18 лет в IT, из них последние 10 в менеджменте, плюс еще 5 лет консалтинга с десятками тимлидов у клиентов. Его позиция проста: миф о том, что карьера тимлида заканчивается бесконечными созвонами, потерей технической формы и зависимостью от одной компании, удобен для страшилок, но плохо совпадает с реальностью найма и развития людей.
Сначала Антонов проходит по четырем главным претензиям к профессии. Первая: тимлид отвечает за все, но формальных рычагов у него мало. Не всегда нанимает сам, не увольняет, бюджетом часто не распоряжается, а отвечать за результат все равно приходится. В его логике это не слабость, а тренажер непрямого влияния: договариваться, убеждать, объяснять решение бизнесу и команде без административной дубинки. Вторая претензия еще ближе многим разработчикам: обязанности у тимлида расползаются во все стороны. Процессы, люди, сроки, конфликты, найм, синхронизация с соседями. Но именно эта «размазанная» зона ответственности потом и превращается в актив: человек собирает набор навыков, который переносится в другие роли заметно лучше, чем знание одного стека или одной кодовой базы.
Самый болезненный страх предсказуемо связан с хард-скилами. Вчера писал код, сегодня сидишь в Zoom, завтра уже не отличишь хороший pull request от плохого. Антонов предлагает неприятную, но полезную мысль: тимлидство надо перестать мерить мерками senior-разработчика. Это другая профессия и другой рынок труда. Да, навык ежедневного кодинга проседает. Но на его месте растут другие «харды»: project management, people management, процессное управление, разговор с продуктом и бизнесом на языке последствий, сроков и денег. Логика сравнения должна быть не «пишу ли я код лучше соседнего сениора», а «стал ли я за полгода сильнее как тимлид». Для многих в российском IT это, вероятно, самый неприятный вывод из всего доклада: проблема не всегда в роли, иногда в том, что человек пытается жить сразу в двух карьерных системах координат.
Четвертый страх касается вендорлока на работодателя. Пять лет в одном контуре, свой стек, свои процессы, свои смежники, а потом рынок спросит: и что ты умеешь вне этого аквариума? Антонов возражает и здесь: тимлидов нанимают не только и не столько за знание конкретной технологии, сколько за управленческие навыки, которые слабо зависят от компании. В качестве контрпримера он приводит переход из веб-разработки в среду, где команда занимается патчингом компилятора C++. Для individual contributor такой разворот выглядел бы почти как смена профессии, а для менеджерской роли он оказывается рабочим сценарием. Это важная поправка для рынка, где многие по привычке оценивают себя через стек, хотя на менеджерских позициях ставка все чаще делается на способность вести команду и доставлять результат.
Чтобы эта логика не висела в воздухе, в докладе есть и приземление к повседневной работе. По версии Антонова, тимлид каждый день делает семь вещей, и они хорошо объясняют, почему карьера тимлида не замыкается на одной табличке в оргструктуре. База — доставлять проекты и задачи в срок. Следом — держать команду эффективной в долгую, а не выжимать из людей максимум на коротком отрезке. Дальше — выстраивать коммуникацию с бизнесом, продуктом, руководителями и смежниками, понимать, откуда в компании берутся деньги, уметь оценивать, кого стоит нанимать, даже если формального права последнего слова нет, и, наконец, не делать лишней работы. Последний пункт Антонов иллюстрирует историей почти на миллион рублей: на оценку принесли проект, тимлид прикинул объем в человеко-год и задал один вопрос — «зачем?». Через две недели выяснилось, что проект не нужен. Итог: год работы и миллион рублей сохранили не за счет героизма, а за счет базовой управленческой дисциплины.
Из этого набора обязанностей и вырастают карьерные развилки. Самая очевидная — middle-management. По наблюдению Антонова, туда обычно приходят не те, кто громче всех хочет должность, а те, кто уже начал мыслить за пределами собственной команды: смотрит на смежников, понимает стратегию направления, умеет делегировать и не пытается одновременно на 80% жить в коде и еще на 80% жить в менеджменте. Часто такое повышение вообще не планируется линейно: компанию покупает крупный игрок, юнит быстро растет, уходит руководитель, начинается реорганизация, и бизнес выбирает человека, который уже тянет нужный уровень. Дальше есть трек в C-level, но здесь доклад полезен именно тем, что сбивает романтику. Образ CTO, который весь день «обмазан технологиями», Антонов фактически отправляет в архив. В реальности это Zoom, почта, Excel, глобальная ответственность за деньги и решения, у которых всегда есть пострадавшие. В одном из приведенных им примеров CTO работает по 10–16 часов в день; в другом на вопрос о work-life balance человек просто смеется. Это не аргумент против роста, а напоминание: высокая должность в IT давно перестала быть просто «еще больше технологий». Есть и более мягкий сценарий: переход из крупной компании в небольшую, где опыта тимлида или мидл-менеджера уже хватает для CTO-роли.
Наконец, доклад разбирает и боковые выходы — то, что обычно недооценивают сильнее всего. Антонов приводит примеры людей с тимлидским бэкграундом, которые ушли в маркетинг и DevRel. Среди них Катя Петрова из подкаста «Подлодка», перешедшая в маркетинг Kotlin, Виталик Шароватов и Антон Чернов, работающий дев-адвокатом в «Яндекс Облаке». Общая идея тут в том, что тимлид уже умеет две вещи, которые на стыке технологий и бизнеса особенно ценны: говорить с бизнесом на языке выгоды и говорить с разработчиками на их собственном языке. Для DevRel это почти обязательный минимум. Более того, по признанию самих практиков, дев-адвокация иногда требует еще больше коммуникации, чем тимлидство: внутри компании, снаружи, с технической аудиторией, продуктом, медиа и комьюнити. Ирония в том, что роль, которую многие считают концом технической карьеры, на деле оказывается хорошей подготовкой к профессиям, где инженерный бэкграунд монетизируется даже шире.
Для русскоязычного IT-рынка вся эта история важна по одной причине: на фоне осторожного найма, долгих согласований и вечной тревоги о «потере формы» люди стали хуже различать, где реальный карьерный риск, а где просто неприятная смена идентичности. Карьера тимлида действительно не для всех, и доклад Антонова это не прячет. Но если смотреть на нее не как на ухудшенную версию senior-разработчика, а как на отдельную профессию с собственными хард-скилами и маршрутами, вопрос меняется. Уже не «застряну ли я в созвонах», а «в какую сторону мне выгоднее конвертировать этот опыт через два-три года».