Вы наверняка встречали задачки на логику: «Все кошки — животные. Это животное — кошка. Значит ли это, что все животные — кошки?» Нет. С тимлидами та же история: не каждый сильный разработчик становится сильным тимлидом. Но и обратное неверно.

Меня зовут Юлия Аравина, я психолог и коуч IT-руководителей, а также наставник на курсе «Управление командой» в Яндекс Практикуме PRO. В этой статье я разберу, в какие ловушки попадают сильные разработчики после повышения, как из них выйти, и как понять, что тимлидство не для вас (или всё же для вас).

Повышение до тимлида — это не апгрейд,  а смена профессии

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

Для сотрудника, особенно новичка, тимлидство кажется самым логичным вектором роста. Многие приходят в IT с убеждением, что карьера устроена линейно: джун → мидл → синьор → тимлид. Хотя вариантов гораздо больше: техлид, архитектор, скрам-мастер. Их часто не рассматривают — и оказываются на должности, которая вызывает дискомфорт.

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

Типичные ловушки после повышения

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

«Лучше сделаю сам»

Разработчику проще сделать задачу самостоятельно, чем объяснять. В роли тимлида эта логика превращает его в «бутылочное горлышко»: команда не растёт, задачи копятся. Раньше он работал 40 часов в неделю разработчиком — теперь работает те же 40 часов разработчиком и ещё 30 руководителем.

За этим стоит более глубокая проблема. Для многих разработчиков мерило собственной ценности — конкретный осязаемый результат: выкатил фичу, закрыл задачу. В управлении так не работает: результат растянут во времени и почти всегда коллективный.

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

Что можно сделать: переформулировать свою ценность. Например: «Моя ценность как руководителя уже не в выкаченной фиче, а в том, насколько замотивирована команда и какой уровень компетентности есть у каждого из её участников».

Нетерпимость к чужим ошибкам

Тимлиды, которые выросли из сильных экспертов, видят, что другие выполняют задачи объективно хуже и медленнее. Реагируют по-разному: дают токсичную обратную связь на ревью, практикуют микроменеджмент — лишь бы всё делалось именно так, как они хотят.

Типичная ситуация: тимлид раз за разом переписывает половину пулреквестов — так быстрее и надёжнее. Разработчики постепенно перестают думать самостоятельно: зачем стараться, если всё равно переделают? Скорость разработки падает, а тимлид только больше убеждается, что окружён некомпетентными коллегами.

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

Фокус на задачах вместо анализа причин

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

Типичная ситуация: один разработчик стабильно не дотягивает. Тимлид перекидывает его задачи на других или закрывает сам — лишь бы не тормозило. При этом не разбирается в причинах, не даёт обратную связь и не помогает человеку расти. Проблема не исчезает, а распределяется между членами команды — страдают все.

Что можно сделать: добавить менеджерский слой к каждой задаче. Спрашивать не только «сделана ли задача», но и «замотивирован ли человек, достаточно ли у него компетенции, достаточно ли чётко задача была поставлена».

Избегание сложных разговоров

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

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

Другая типичная ситуация: тимлид не избегает сложных разговоров, но не считает нужным думать о том, как их вести. Говорит резко — и однажды обнаруживает, что сотрудник положил заявление на стол. Если грубые комментарии на ревью стали нормой, можно в один день потерять человека, которому такой стиль просто не подходит, — особенно новичка!

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

Отсутствие системного мышления

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

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

Что можно сделать: перенести фокус с конкретных задач на процессы. Смотреть не только на то, что происходит прямо сейчас, но и на то, что может помешать команде завтра — и договариваться об этом заранее.

Как перестроиться в новую роль

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

— Создать новый definition of done. Для разработчика критерий результата очевиден: закрыл задачу — готово. У тимлида так не работает. Результат размыт во времени, почти всегда коллективный, и его сложно пощупать. Поэтому важно переопределить его явно — сформулировать самому и согласовать с руководителем. 

Как пример: «За полгода нанять пять разработчиков, выстроить процесс адаптации, выделить наставников, через девять месяцев присоединить их к фича-командам — чтобы новички быстро вливались и уже давали бизнес-результат». Вот это и есть критерий на год. Поставил, согласовал — работаешь.

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

— Выстроить регулярные встречи один на один. Эта практика есть во многих компаниях, но почти везде она первой исчезает под давлением дедлайнов. Я постоянно сталкиваюсь с тем, что где-то её до сих пор нет вообще.

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

— Сформулировать метрики командной эффективности. Количество выпущенных фич? Скорость поставки? Количество доработок после релиза? Качество кода? Важно не просто выбрать метрики, но и сделать их очевидными для команды — в идеале связать с OKR или KPI. И объяснить, почему они важны. Люди работают лучше, когда понимают, в чём измеряется их результат и зачем это нужно бизнесу. Без этого команда может работать старательно, но вслепую.

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

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

— Отпустить контроль и довериться делегированию. Думать не «как мне это сделать», а «через кого я могу это сделать и что этому человеку нужно». Делегировать по-настоящему — значит принять, что задача будет выполнена иначе, чем сделал бы ты сам. Иногда хуже. Иногда лучше. Но только так команда растёт, а тимлид перестаёт быть «бутылочным горлышком».

Кому точно не стоит идти в тимлиды

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

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

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

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

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

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

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

— Если категорически не приемлете политику. Как только становишься управленцем, столкновение с корпоративной политикой неизбежно. Это не значит, что нужно интриговать или играть в закулисные игры — речь о другом: отстаивать ресурсы для команды, договариваться с другими руководителями, выстраивать альянсы внутри компании.

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

— Если цель тимлидства — власть и статус. Если главная мотивация — получить влияние, а не выстроить работающую команду, это рано или поздно станет заметно. И команде, и руководству. Ничего хорошего из этого не получится.

Заголовок этого раздела звучит категорично — но на самом деле я за то, чтобы давать людям надежду. Всё узнаётся в практике. У кого-то может быть иллюзия, что управление вообще не про него, — но в процессе человек втягивается и понимает, что ему подходит, а что нет. 

И даже если несколько пунктов из списка выше — про вас, это не приговор. Одни качества поддаются развитию: навык вести переговоры или давать обратную связь можно осознанно прокачивать. Другие — сигнал, что нужно выстроить систему под себя. Третьи стоит просто честно взвесить — не как повод отказаться, а как исходные данные для осознанного решения. 

Поэтому я за то, чтобы пробовать — и делать это в безопасных форматах. Можно начать с наставничества. Например, взять на себя роль бади — сопровождать новичков, отвечать на вопросы, почувствовать эмоциональную составляющую работы с людьми. Или изучить платформы интеллектуального волонтёрства, где НКО ищут помощь с проектами: там можно взять на себя роль руководителя и понять, как это ощущается, — без карьерных рисков.

Напоследок

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

Если интерес всё же есть — не меняйте роль, меняйте систему. Найдите конкретную болевую точку и разберитесь с ней прицельно. Сложно делегировать — возможно, нужна прозрачная система контроля, где видны все задачи. Нет уверенности в команде — значит, компетенции нужно проверить, или дать время, или осознанно пойти на риск. Дискомфорт в новой роли почти всегда конкретен. И почти всегда с ним можно что-то сделать.

Бывает показательная история: человек говорит «ухожу, возвращаюсь в разработку» — а потом в пятой компании подряд его снова повышают. Может быть, это неспроста. Управленческий потенциал иногда виден окружающим лучше, чем самому человеку. И пока он раз за разом менял место, он мог бы уже вырасти.

Роль тимлида — не награда за хорошую техническую работу и не логичный следующий шаг. Это другая профессия, со своими критериями результата, своими инструментами и своими сложностями. Кому-то она подходит, кому-то — нет. Но понять это можно только в практике.