Шесть лет успешной работы с командой того же размера — и ни шага вверх: такой сценарий описал инженерный руководитель Кевин Голдсмит. Его история показывает, как карьерная ловушка руководителя превращает стабильный результат в препятствие для повышения: чем лучше команда закрывает задачи, тем охотнее ей добавляют новые, но не стратегические полномочия. Для российских IT-лидов это знакомая развилка между ролью «того, кто всегда вытянет релиз» и человека, который влияет на решения компании.
Как сообщает Habr / Карьера, Голдсмит возглавлял проект с новыми для компании технологиями и почти без внутренней поддержки. Чтобы команда закрепилась, он договаривался со стейкхолдерами и соглашался на широкий круг запросов. Команда справлялась, её ценили, а поток задач рос. Формально это выглядело как успех: больше доверия, больше работы, признание на оценках эффективности. На практике спустя несколько лет руководитель остался в той же роли, без расширения влияния за пределы собственной команды.
Проблема не в том, что компания обязательно хочет наказать сильного менеджера. Она реагирует на понятный сигнал: подразделение выполняет обещания, значит, его можно нагружать дальше. Хорошее исполнение укрепляет доверие к исполнению — но само по себе не доказывает, что человек умеет выбирать направление, распределять ресурсы между инициативами и спорить с приоритетами. Это разные типы доверия, и автоматического перехода между ними в оргструктуре обычно не происходит.
В результате возникает неприятная математика. Чем больше критичных задач принимает на себя руководитель, тем меньше у него времени на планирование, переговоры с соседними функциями, анализ рисков и формулирование позиции о будущем продукта или направления. А отсутствие такой позиции окружающие могут принять не за дефицит времени, а за отсутствие стратегического мышления. Карьерная ловушка руководителя замыкается: его считают незаменимым в текущем контуре и потому слишком ценным, чтобы перевести на следующий уровень.
Голдсмит разделяет управление текущей работой подразделения и определение его будущего. В первом случае руководитель следит за поставкой, качеством, сроками и людьми. Во втором — объясняет, что команде стоит делать через год, от каких проектов отказаться, где нужны инвестиции и какие последствия будут у решения. Если такую картину не предлагает сам руководитель команды, её по умолчанию формирует его начальник. Именно эта версия затем попадает в обсуждения с топ-менеджментом или советом директоров.
В статье приведён типичный контраст между двумя управленческими стилями. Одна руководительница брала на себя слишком много, работала допоздна и добивалась высоких результатов силами перегруженной команды. В ответ ей поручали ещё больше критически важных задач, а ресурсов не добавляли: снаружи команда продолжала выполнять показатели. Параллельно коллеги с меньшим объёмом поставки чаще рассказывали руководству о планах и ограничениях — и получали дополнительную поддержку. Когда у первой команды ухудшилось состояние людей, менеджер получила не рычаги для исправления ситуации, а замечания по моральному климату.
Для разработчиков и тимлидов здесь нет призыва бросить операционную работу или имитировать стратегию слайдами. Скорее, речь о том, чтобы не считать планирование факультативным занятием «после всех срочных задач». Руководителю нужны регулярные разговоры о том, какие обязательства команда больше не может брать, какой эффект дают уже сделанные проекты, какие компетенции или люди требуются дальше. Важно приносить не только статус «всё сделаем», но и выбор: что компания выиграет или потеряет при каждом варианте приоритетов.
Бизнесу эта история тоже обходится дорого. Менеджер, который тащит всё на личной надёжности, создаёт краткосрочную устойчивость и долгосрочный риск: команда выгорает, знания концентрируются в одном контуре, а следующий управленческий уровень остаётся без подготовленного преемника. Повышение в такой модели откладывается не из-за плохих результатов, а потому что система не научилась работать без человека на его нынешнем месте.
Главный вопрос для любого сильного IT-руководителя звучит неприятно, но полезно: команда просто хорошо обслуживает растущий поток запросов или уже может объяснить, какие запросы компании вообще нужны? Пока ответом остаётся первое, карьерный рост будет зависеть не от количества закрытых задач, а от готовности освободить место для решений, которые не помещаются в очередной спринт.
