Одарённый исполнитель не равно хороший руководитель
В начале 2025 года мы сидели в переговорке московского офиса одной из крупных российских IT‑компаний — разработчика облачных решений для банков. Технический директор пригласил нас на консультацию по поводу управления командой. Одной из историй, которую он рассказал, мы решили поделится. Она про повышение по службе талантливого программиста. Парень отличный исполнитель. Но до того, как стать еще и хорошим руководителем, он чуть не погубил команду. Решение оказалось оригинальным и действенным.
Звезда команды
Речь пойдет о повышении по службе Михаила. Он был тем самым разработчиком, о котором пишут в чатах: «Если не работает — зови Мишу». Его pull request’ы проходили ревью с первого раза. Он ловил баги, которые другие не видели даже под дебаггером. Его производительность — в два раза выше средней по команде. Когда ушёл тимлид (переманили), решение казалось очевидным: «Лучший в строю — на командирское место».
Он согласился. Через четыре месяца команда из восьми человек была на грани распада.
Ловушка №1: «Я сделаю быстрее». Михаил, как и многие технические гении, перешёл в режим спасателя. Вместо того чтобы делегировать, он брал самые сложные задачи себе. «Так надёжнее. Так быстрее». Он не доверял, не учил, не объяснял — просто делал.
Но тут срабатывает закон: если руководитель решает задачи, он перестаёт управлять. Вместо того чтобы настраивать процессы, он сидел за монитором до полуночи, исправляя чужой код. А простые задачи — те, на которых растут джун и миддл — в итоге делались кое‑как, потому что никто не проверял.
Компания начала терять и кодера, и лидера. Он лично падал в производительности, а команда — в мотивации.
Ловушка №2: «Где мой дофамин?». Раньше Михаил получал удовольствие от конкретики: чистый код, зелёные тесты, закрытый баг. Это был его дофамин — и он работал. Теперь его день состоял из встреч, отчётов, конфликтов, согласований. Он почти не писал код. Его личный вклад в продукт упал до 20%.
Он не чувствовал себя профессионалом. Он чувствовал себя… чиновником и бюрократом. И тут случается кризис самооценки: человек теряет точку опоры. Он больше не знает, где его зона силы. Он не понимает, за что его хвалят. Раньше — за красивое решение. Теперь — за то, что «вовремя отправил отчёт». Это как боксёру вручить грамоту за аккуратное ведение табеля.
Ловушка №3: «Процессы — это бюрократия». Михаил считал, что «встречи — трата времени», «стендапы — формальность», «ретроспективы — пустая болтовня». Он отменял их. Не было понимания, что процессы — это не про контроль, а про безопасность команды. Без них роста не будет. Без них новички не включаются. Без них появляются тени — закрытые чаты, недоверие.
Команда разделилась. Одни — те, кто работал в офисе, — обсуждали проблемы «у кофе‑машины». Другие — удалёнщики — создали свой канал. Никто не знал, что делает сосед. Спринты срывались. Технический долг полз вверх.
Ловушка №4: «Я остался своим парнем». Раньше Михаил был тем, к кому можно было подойти: «Миша, помоги, не понимаю». Теперь — он начальник. Он перестал быть доступным. А когда пытался быть «своим», это выглядело как слабость. Он не учил — он переписывал код за другими ночью, без объяснений.
Один из миддлов, уходя, сказал: «Я пришёл учиться у Миши. А он стал недоступным. Исправляет мой код молча и без комментариев. Зачем мне здесь быть?».
Ловушка №5: «Я не вижу картину». Новоиспеченный руководитель погрузился в код… и забыл про менеджера продукта. Две недели команда делала не ту фичу — ту, которую он сам считал нужной, а не ту, которую просил банк. Переделывали “в огне”.
Руководитель — это не тот, кто делает. Это тот, кто обеспечивает результат через других. А навыков делегирования, контроля, коммуникации у него не было.
Рассылка: как вести бизнес в России
Пять полезных писем пришлем сразу после подписки. В них — бизнес‑идеи, готовые промпты для нейросетей, советы, как выбрать налоговый режим и получать пассивный доход
Как это исправили?
Технический директор (сам бывший программист) не стал снимать Михаила. Он применил гибкий подход.
Расщепление роли и создание тандема. Михаилу оставили титул и сильную сторону — техническое лидерство (архитектура, код‑ревью). Но в пару к нему ввели «менеджера проекта», который взял на себя нетехнические аспекты: коммуникацию, планирование, 1:1 встречи. Это сняло непосильную нагрузку.
Практическое наставничество. На 2 месяца к Михаилу прикрепили внешнего Scrum‑коуча, который внутри команды, на живых спринтах, показывал, как проводить планирование, ретро и делегировать ответственность.
Систематизация. Чтобы снизить тревогу за качество, Михаил систематизировал свой опыт: создал чек‑листы для код‑ревью и шаблоны для микросервисов. Теперь он влиял на качество, задавая стандарты, а не правя каждый коммит.
Даже систему мотивации и KPI пересмотрели: «Раньше твой KPI — это твой код. Теперь твой KPI — это скорость роста мидлов в команде и снижение критических багов на 30%». Это позволило снова получать «дофамин», но уже от успехов команды.
Управление — отдельная профессия
История Михаила — не исключение. За этот год мы видели подобное в нескольких компаниях.
Лучший исполнитель — не автоматически лучший руководитель. Управление требует других навыков: делегирование, коммуникация, эмпатия, стратегическое мышление. Оно требует другой мотивации: не личный результат, а результат команды. Оно требует другой системы поддержки: наставничество, чёткие KPI, защита от перегруза.
Если вы просто «повышаете» звёздного разработчика — вы рискуете потерять и его, и команду. Но если вы готовите лидера, а не просто ставите в кресло — вы получаете силу, которая умножается.
