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

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

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

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

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

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

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

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

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

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

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

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

Работа, которой не видно

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

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

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

Обратная связь

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

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

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

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

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

Грейды надо описать

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

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

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

Мои ошибки

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

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

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

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

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

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

Почитать