~ / blog / from-developer-to-lead
from-developer-to-lead.md — vim
4 августа 2026 г. ⏱ ~4 мин · командамыслипроцессы

Из разработчика в лида: что меняется на самом деле

Выглядит как повышение, а по факту это смена профессии. Про исчезнувшую обратную связь, невидимую работу и ошибки, которые я успел совершить.

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

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

Результат теперь не твой

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

К этому привыкаешь не сразу. Первые месяцы регулярно тянет пойти покодить, чтобы почувствовать себя полезным. Кодить, кстати, стоит — но маленькие изолированные куски, не критический путь. Лид на критическом пути становится бутылочным горлышком ровно в тот день, когда его дёрнут на три встречи подряд.

Ошибки лида стоят дороже

Ошибка разработчика стоит несколько часов и правится в PR. Ошибка лида - это стек, который команда тащит два года, или человек, которого не отпустили вовремя.

Практический вывод, к которому я пришёл: делить решения на обратимые и необратимые. Обратимое (структура папок, библиотека для дат, формат коммитов) - принимай быстро и не собирай комитет. Необратимое (фреймворк, схема данных, найм) - собирай мнения, пиши документ, проверяй на прототипе.

Больше всего времени я потерял, обсуждая обратимые решения так, будто они необратимые.

Невидимая работа тимлида

Что не отображается в трекере, но занимает половину времени:

  • договориться со смежниками, чтобы задача вообще стала возможной;
  • перевести хотелку бизнеса в требования, из которых можно оценить срок;
  • убрать из планов то, что делать не надо (вообще самое ценное занятие);
  • заметить, что человек выгорает, до того как он напишет заявление;
  • объяснить наверх, почему техдолг это не «программисты хотят порефакторить».

Последнее - отдельный навык. «Нам нужно две недели на рефакторинг» не продаётся никогда. «Сейчас каждая правка в этом модуле занимает три дня вместо одного и в трети случаев вызывает баг, за две недели мы это уберём» - продаётся почти всегда. Разница в том, что второе сказано на языке денег и рисков. Если под рукой есть метрики доставки, разговор становится ещё короче.

Как давать обратную связь команде

Худшее, что делает начинающий лид, - копит недовольство до квартальной встречи. Через три месяца человек услышит про ошибку, которую уже не помнит, и обидится. Справедливо.

Что работает у меня:

Регулярные один на один. Раз в две недели, полчаса-час, повестка у сотрудника, а не у меня. Это не статус по задачам - статус есть в трекере. Это про то, что мешает, что интересно и куда человек хочет расти.

Факты вместо ярлыков. Не «ты невнимательный», а «в трёх последних PR были падения из-за необработанного null, давай подумаем, как ловить это раньше».

Хвалить публично, критиковать лично. Банальность, которую нарушают постоянно.

Зачем описывать грейды и матрицу компетенций

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

Эффект оказался не в том, что стало проще повышать. Людям стало понятно, что делать. Вопрос «почему я не сеньор» превратился в «мне не хватает вот этого, где взять такой опыт». Performance review из неприятной процедуры стал рабочим инструментом.

И отдельно: грейд не выдаётся за выслугу. Год работы сам по себе навыков не добавляет, если весь год делать одно и то же.

Мои ошибки в роли лида

Пытался быть лучшим разработчиком в команде. Это не роль лида, и людям это мешает расти - зачем разбираться, если лид всё равно перепишет.

Слишком долго не расставался с теми, кто не тянет. Все всё видят раньше, чем ты решаешься. И платят за это те, кто тянет.

Микроменеджерил из лучших побуждений. «Я просто помогу с деталями» читается как «я тебе не доверяю».

Делегировал задачи, но не полномочия. Отдал задачу, но каждое решение согласовывают со мной - это не делегирование, а очередь ко мне.

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

Хороший лид измеряется не тем, как он пишет код, а тем, как команда работает без него в комнате. Метрика неудобная, зато честная.

Почитать