Есть одна управленческая боль, о которой в ИТ говорят гораздо реже, чем стоило бы. Хотя сталкиваются с ней очень многие. Особенно тимлиды, engineering managers и руководители команд в растущих компаниях, где приоритеты постоянно двигаются, продукты конкурируют за ресурсы, а сильных людей стараются перебрасывать туда, где сейчас самый большой пожар или самая важная ставка.
Проблема в том, что внешне такая ситуация выглядит почти как успех. Ты растишь человека, вкладываешься в него, помогаешь ему пройти через ошибки, неуверенность, сложные задачи и внутренние барьеры. Потом он становится заметным, автономным и сильным. Его начинают видеть другие команды. Его хотят к себе. Формально это признание качества твоей работы. Но внутри это очень часто ощущается не как успех, а как потеря.
Я думаю, это чувство знакомо многим, кто хотя бы несколько лет управлял людьми в разработке. Ты можешь полгода собирать инженера буквально по слоям. Сначала он боится брать ответственность и постоянно сверяется с тобой. Потом учится принимать решения, но еще не умеет держать последствия. Потом начинает разбираться в продукте, контексте, соседних системах, зависимостях, людях, компромиссах. Ты постепенно даешь ему все более сложные задачи. Не потому что хочется просто нагрузить человека. А потому что понимаешь, что без этого он не вырастет.
На этом пути руководитель делает огромное количество незаметной работы. Он не просто выдает задачи и оценивает результат. Он объясняет, почему именно эта задача важна. Он помогает не развалиться после ошибки. Он удерживает баланс между свободой и контролем. Он вовремя защищает человека от лишнего давления. Он помогает не только писать код, но и думать шире. Про архитектуру, про риски, про взаимодействие с продуктом, про влияние решений на соседние команды. И в какой то момент ты видишь, что инженер действительно вырос. Уже не теряется, не бежит за подтверждением каждого шага, сам держит зону ответственности и начинает приносить команде не эпизодическую, а устойчивую пользу.
И вот именно в этот момент обычно и приходит тот самый сигнал, который знаком многим руководителям.
Нам очень нужен этот человек в другой команде.
У них критический проект.
У них не хватает зрелых рук.
Там сейчас важнее.
Ты же умеешь растить людей.
Ты еще одного подготовишь.
На бумаге это может выглядеть логично. В организации все вроде бы происходит ради общего результата. Но на эмоциональном уровне в такой момент очень часто поднимается смешанное чувство. С одной стороны, ты действительно гордишься человеком. Потому что его рост настоящий. Потому что ты знаешь, сколько туда было вложено времени, внимания, терпения и управленческой работы. С другой стороны, тебя накрывает раздражение. Иногда даже обида. Потому что в этой логике твой труд начинают воспринимать как что то бесконечно воспроизводимое. Как будто твоя команда не живая система с реальной нагрузкой, ограничениями и рисками, а какой то внутренний инкубатор по выпуску готовых сильных инженеров.
И вот здесь начинается самая неприятная часть. Очень долго может казаться, что тебя выжигает сам факт потери сильного человека. Но по моему опыту выжигает не это. Настоящая причина глубже. Сильнее всего истощает ощущение, что стоимость твоей работы не видна. Что все замечают красивый результат, но никто не хочет замечать цену, по которой он был получен.
Потому что растить инженера это не магия. И не случайность. И точно не побочный эффект существования команды. Это очень тяжелая и долгая управленческая работа. Там нет одной большой героической победы. Там есть сотни маленьких решений. Когда дать человеку ошибиться, а когда подстраховать. Когда стоит промолчать, чтобы он сам дошел до ответа, а когда лучше остановить и объяснить. Когда дать видимость и публичность, а когда наоборот защитить от слишком раннего давления. Когда push полезен, а когда он ломает. Когда развитие помогает команде, а когда команда просто не выдерживает темп роста сразу нескольких людей.
Если организация забирает у тебя готового сильного инженера, она получает не просто конкретного человека. Она получает результат длинной цепочки этой работы. И если это не признается, у руководителя постепенно возникает очень опасное состояние. Не яркий, громкий, очевидный burnout, который все замечают. А тихий внутренний цинизм. Он гораздо коварнее.
Ты начинаешь чуть меньше вкладываться.
Чуть осторожнее делиться возможностями.
Чуть реже давать сильным людям слишком заметные задачи.
Чуть дольше держать человека рядом с собой, даже когда ему уже пора идти шире.
Иногда даже неосознанно замедляешь развитие, потому что уже слишком хорошо понимаешь, чем обычно заканчивается успех.
Это опасно не только для компании. Для компании это тоже плохо, потому что она сама убивает культуру развития. Но в первую очередь это опасно для самого руководителя. Потому что в этот момент он перестает работать из зрелой управленческой позиции и начинает защищаться от боли. Снаружи это может выглядеть как рациональность. На деле это уже внутренняя деформация роли.
У меня в какой то момент произошел важный сдвиг в восприятии этой истории. Я понял, что если моих людей забирают на сложные задачи, то это не всегда значит, что я просто теряю их в пустоту. Часто это означает, что мое влияние начинает выходить за пределы одной команды. Через какое то время в соседних направлениях оказываются люди, с которыми у меня уже есть доверие, общий язык, нормальная рабочая память о том, как мы вместе принимали решения. Они уносят с собой не только свои навыки. Они уносят подход к качеству, к ответственности, к коммуникации, к отношению к системе, к инженерной дисциплине. Они становятся точками опоры в других местах организации.
Это не отменяет неприятных эмоций. Не надо делать вид, что одна красивая философия моментально лечит все. Не лечит. Но это действительно помогает увидеть смысл там, где раньше виделась только потеря.
При этом очень важно не скатиться в другую крайность и не пытаться решить структурную проблему только внутренней зрелостью. Условно говоря, мало сказать себе, что это все ради общего блага. Если команда отдает сильного инженера, это должно иметь последствия для планирования, ожиданий и нагрузки. И об этом нужно говорить прямо.
На мой взгляд, это одна из типичных ошибок молодых руководителей. Им кажется, что хороший менеджер должен все выдерживать молча. Должен адаптироваться, не жаловаться, не показывать стоимость изменений, быть максимально удобным для системы. Я сам в начале карьеры думал примерно так же. Мне казалось, что если я начну обсуждать последствия такого перехода, это будет выглядеть как слабость или как попытка удержать людей ради собственных интересов.
Со временем стало понятно обратное. Когда ты молча перевариваешь каждую такую потерю, ты обучаешь организацию плохому паттерну. Она привыкает, что именно из твоей команды людей можно забирать без серьезных последствий. Не потому что последствий нет, а потому что ты их не артикулируешь. И тогда твоя устойчивость начинает работать против тебя. Тебя воспринимают как бесконечно прочную конструкцию. А потом удивляются, почему ты однажды приходишь уставшим, раздраженным и больше не хочешь никого развивать.
Поэтому одна из ключевых вещей, которые я для себя вывел, заключается в следующем. Нужно перестать молча соглашаться на такие переходы без разговора о цене решения. Не в формате истерики, не в формате обиды, не в формате шантажа. А в формате взрослого управленческого разговора.
Если команда отдает сильного инженера, что это значит для roadmap.
Какие задачи теперь объективно замедлятся.
Где вырастут риски.
Какие зоны останутся без достаточной глубины.
Нужен ли пересмотр ожиданий по срокам.
Нужен ли backfill.
Нужно ли временно сократить объем параллельных инициатив.
Насколько готова команда пережить такой переход без системного проседания.
Это не эмоции. Это управленческая реальность. И если руководитель ее не озвучивает, никто не обязан угадывать ее самостоятельно.
Еще одно важное изменение, которое мне очень помогло, связано с самим форматом менторства. Когда ты понимаешь, что человек с большой вероятностью скоро пойдет дальше, недостаточно просто сделать его сильнее лично. Нужно сделать так, чтобы его рост не оставил после себя пустоту. И вот тут менторство превращается из истории про одного человека в историю про систему.
Что это значит на практике. Это значит, что знания не должны оставаться только в голове одного сильного инженера. Решения должны быть зафиксированы. Критический контекст должен быть объяснен другим. Документация должна быть не для галочки, а реально рабочей. Важные сервисы и процессы должны быть понятны не только владельцу. Передача ответственности должна происходить до перехода, а не после него в аварийном режиме.
Очень часто руководители страдают не только от того, что у них забирают сильного человека, но и от того, что вместе с ним уходит огромный кусок структуры, которую никто специально не делал явной. Оказывается, что этот человек держал в голове половину неформального знания о системе, основные договоренности, историю технических компромиссов, особенности соседних сервисов, реальные причины старых решений. Пока он был рядом, это не чувствовалось. После ухода внезапно появляется дыра.
Чтобы такого не происходило, сильного инженера важно учить не только хорошо делать свою работу, но и оставлять после себя порядок. Это очень взрослый навык. По сути, один из признаков зрелости инженера состоит не только в том, как много он может взять на себя, но и в том, насколько после него система остается понятной другим.
И здесь роль руководителя критична. Именно он может вовремя сместить акцент с индивидуальной экспертизы на передачу знаний. Он может попросить человека провести внутреннее демо, оформить runbook, зафиксировать архитектурные решения, разложить логику сервиса, передать ритуалы взаимодействия со смежниками. Это не бюрократия. Это способ не превращать каждый переход сильного человека в микро катастрофу для команды.
Есть и еще один важный слой, про который редко говорят. Руководитель очень часто бессознательно связывает свою профессиональную идентичность с текущей силой команды. Это естественно. Команда становится отражением твоей работы. Ты смотришь на сильных людей вокруг и думаешь, что это и есть подтверждение твоей эффективности. И в этом есть правда. Но есть и ловушка.
Если твое ощущение собственной ценности слишком сильно завязано на том, чтобы все сильные люди оставались рядом именно с тобой, любой переход будет переживаться как личное ослабление. Ты будешь чувствовать, что тебя как будто обнулили. Что у тебя забрали результат труда. Что тебя сделали менее значимым.
На более зрелом уровне картина другая. Сильный руководитель это не тот, кто любой ценой удерживает лучших рядом. И не тот, кто создает вокруг себя замкнутую лояльную экосистему. Сильный руководитель это тот, после которого люди растут, а система не ломается. Тот, у кого команда умеет переживать движение людей. Тот, чье влияние продолжается даже после того, как человек ушел в другой продукт, другой домен или вообще другой бизнес внутри компании.
Это более сложная, но и более здоровая модель профессиональной идентичности.
При этом я совсем не хочу романтизировать такие истории. Бывают ситуации, когда переход происходит в очень плохой момент. Бывает, что у тебя и так перегруженная команда. Бывает, что сверху даже не пытаются обсуждать последствия. Бывает, что это уже третий сильный человек за короткий период. Бывает, что от тебя ждут того же результата, как будто ничего не изменилось. В такие моменты любые красивые слова про развитие людей начинают звучать раздражающе. И это нормально. Не нужно требовать от себя идеальной зрелости в момент, когда система очевидно ведет себя небрежно.
Но даже в таких ситуациях мне помогала одна очень простая вещь. Полезно встретиться с человеком перед переходом и честно посмотреть на ситуацию его глазами. Не как руководитель, который должен правильно отреагировать. А как человек, который хочет вспомнить, зачем вообще все это делал. Когда видишь в другом человеке не просто ресурс, а реальную внутреннюю динамику, многое встает на место. Ты слышишь не только про новую роль или новый проект. Ты слышишь про страх, про амбицию, про ощущение роста, про готовность к следующему шагу. И это возвращает смысл всей истории.
В какой то момент становится очень ясно, что твоя работа была не про красивые отчеты и не про удержание людей любой ценой. Она была про то, чтобы рядом с тобой кто то стал сильнее, взрослее и увереннее. И да, иногда это приводит к тому, что этот человек идет дальше уже не с тобой. Но это не делает твою работу менее ценной.
На уровне организации здесь тоже есть важный вывод. Компании любят говорить, что поддерживают внутреннюю мобильность, развитие людей, карьерный рост и культуру лидерства. Все это звучит правильно. Но за этими словами часто не видят реального механизма. А механизм очень простой. Внутреннюю мобильность строят конкретные руководители, которые каждый день инвестируют в развитие людей. Если компания хочет такой культуры, она должна поддерживать не только самих растущих сотрудников, но и тех, кто делает этот рост возможным.
Это означает, что развитие людей должно учитываться в оценке менеджеров.
Это означает, что после перевода сильных людей ожидания по команде должны корректироваться, а не оставаться прежними по инерции.
Это означает, что умение выращивать сильных инженеров должно восприниматься как стратегическая компетенция, а не как бесплатная сервисная функция.
И это означает, что нельзя бесконечно пользоваться одной и той же сильной командой как источником донорства, не разрушая при этом мотивацию ее руководителя.
Пожалуй, главный вывод, к которому я пришел, звучит так. Не нужно становиться ни удерживающим собственником людей, ни молчаливым донором. Обе крайности вредны. Если ты умеешь выращивать инженеров, это нужно воспринимать как реальную сильную сторону. Ею стоит гордиться. Но ее также нужно защищать. Называть ее цену. Выстраивать процессы так, чтобы команда могла переживать переходы. Не позволять системе путать твою устойчивость с бесконечной емкостью.
Сильный руководитель не тот, у кого никто не уходит. И не тот, кто безропотно отдает лучших и делает вид, что ему все равно. Сильный руководитель тот, кто умеет помогать людям расти, при этом сохраняя жизнеспособность команды и собственный ресурс.
Это намного труднее, чем просто растить людей.
Но именно в этом и состоит настоящее управленческое мастерство.
Если вам близки темы engineering management, развития команд, лидерства и реальной управленческой практики в IT, подписывайтесь на мой Telegram канал:
https://t.me/pavelsengineeringstuff
Там я регулярно пишу про сложные управленческие ситуации без лишней теории и с опорой на реальный опыт.