Незаменимых не повышают? Вот и нет

Незаменимых не повышают

Есть такая история про колхозного коня. Пахал лучше всех, не болел, план перевыполнял. Премию в конце года получил бригадир. Конь получил новый участок. И это не несправедливость — это логика. Система сделала ровно то, для чего создана: удержала ценный ресурс там, где он уже работает.

Вопрос к вам: вы точно не этот конь?

Это не несправедливость, это наука

В 1988 году исследователи Левитт и Марч описали феномен, который назвали competency trap ^[1] — ловушка компетентности. Механика простая: чем лучше человек делает что-то одно, тем меньше у системы стимулов его переключать. Зачем трогать то, что работает? Организация вознаграждает вас за текущую роль — и тем самым фиксирует в ней.

Это работает не только с людьми. Kodak ^[2] был абсолютным лидером в плёночной фотографии — вплоть до того момента, как плёнка перестала существовать как рынок. Nokia делала лучшие телефоны в мире — именно поэтому она пропустила момент, когда "телефон" перестал быть просто телефоном.

Лоуренс Питер в 1969 году описал ^[3] другую грань той же проблемы: люди растут по карьерной лестнице до тех пор, пока не достигают уровня своей некомпетентности. Об этом принципе написано много. Но есть обратная сторона, о которой говорят значительно реже: незаменимого сотрудника не повышают вообще, потому что его слишком дорого терять на текущем месте.

Возьмём конкретный пример. Аналитик данных в продуктовой команде. Единственный человек, который знает всю историю метрик, умеет строить дашборды, которые реально используют, и объясняет цифры так, что понимает даже маркетинг. Его ценят. На него завязано. Именно поэтому, когда открывается позиция лид-аналитика или продакта — разговор заходит о ком угодно другом. Переводить его некуда. Он нужен здесь.

Что думал Джобс — и почему это важнее, чем кажется

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

И вот здесь Джобс встаёт в полный рост и говорит: нет. ^[4]

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

Он ненавидел "профессиональных менеджеров", то есть людей, которые умеют выстраивать процессы, но не могут отличить хорошее решение от плохого. У них нет понимания, рождённого из личного исполнения. Такой менеджер управляет тем, что происходит, но не понимает, что происходит на самом деле. Его легко обмануть, ему легко продать плохое решение в красивой упаковке.

Исследователи правы в том, что быть идеальным исполнителем — это ловушка. Но они не дают ответа на вопрос: а что тогда? Джобс даёт. Не "перестань исполнять". А "начни владеть".

Это подтверждают и данные. В 2008 году Google запустил исследование Project Oxygen ^[5]. Они пытались доказать, что менеджеры в технологической компании не нужны. Доказали обратное. Среди ключевых факторов эффективного менеджера техническая экспертиза оказалась важнее управленческих навыков. Команда должна уважать руководителя как профессионала, а не только как координатора встреч.

Тогда в чём вопрос?

Если быть отличным исполнителем = ловушка, то что делать? Два очевидных пути, и оба плохие.

Первый: становиться глубоким экспертом в своей области. Лучший бэкенд-разработчик в команде, senior без вопросов, человек к которому идут за советом. Итог — competency trap. Тебя не трогают, потому что ты слишком нужен здесь.

Второй: не углубляться, распыляться, пробовать всё подряд. Немного аналитики, немного управления, немного стратегии. Итог — тебя не воспринимают всерьёз. Ни команда, ни бизнес. Потому что ты ни в чём по-настоящему не разбираешься, и это видно.

Выход не в том, чтобы выбрать одно из двух. Выход в другом вопросе: на чьей повестке ты работаешь?

Можно быть глубоким экспертом — и при этом иметь свою повестку. Инициировать, ставить задачи, которых ещё никто не поставил, брать ответственность за направление, а не только за исполнение. Тогда экспертиза перестаёт быть клеткой и становится авторитетом.

Именно это имел в виду Джобс, говоря об individual contributor. Не "человек, который хорошо делает свою работу". А человек, который владеет своей работой — и через это владение влияет на всё вокруг.

Проджект без экспертизы — дорогой координатор

Это логично переводит нас к отдельному вопросу: зачем нужен project manager или product manager, который не понимает работу изнутри?

Такой менеджер не может самостоятельно оценить сложность задачи. Его легко ввести в заблуждение (намеренно или нет). Разработчик говорит "это займёт две недели", дизайнер говорит "это принципиально важно для UX", аналитик говорит "данных недостаточно для решения" и проджект просто транслирует это выше, потому что ему нечем проверить. Он управляет процессом, но не качеством.

Альтернатива - выращивать менеджеров из специалистов. Разработчик, который вырос в тимлида, знает, где в оценках обычно врут и почему. Дизайнер, который перешёл в продакты, понимает разницу между "красиво" и "работает". Аналитик, взявший ownership над продуктовым направлением, задаёт правильные вопросы ещё до того, как данные собраны.

Такого менеджера не проведёшь. Он шарит за технику — значит, команда его уважает. Он умеет организовать процесс — потому что прошёл через него сам. И он драйвит не потому что "так написано в джоб-дескрипшне", а потому что понимает, куда и зачем.

Именно поэтому в сильных продуктовых компаниях так много менеджеров с техническим или дизайнерским бэкграундом. В успешных компаниях (например, Apple, Microsoft, NVidia) менеджеры часто выходят из инженеров. Это не случайность. Это осознанная ставка на craft-based judgment.

Тихий IC — невидимый актив

Теперь другая крайность, о которой говорят ещё меньше.

Можно быть отличным специалистом с внутренним ownership — и при этом быть полностью невидимым. Делать крутую работу в своём углу. Не инициировать ничего за пределами своих задач. Не транслировать своё отношение на команду.

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

Для команды это тоже потеря. Один проактивный человек с ownership меняет динамику всей рабочей группы. Исследователь Эми Эдмондсон показала, что в командах с высоким психологическим доверием внутренняя экспертиза используется принципиально лучше — люди не боятся поднимать вопросы, предлагать решения, указывать на риски. Тихий IC лишает команду именно этой энергии.

Задача менеджера здесь — активно искать таких людей и давать им межкомандные проекты. Их отношение к работе заразно. Оно ретранслируется на всю группу. Один разработчик с ownership в кросс-функциональной команде способен изменить то, как эта команда принимает решения.

Баланс: между инициативой и системой

Есть и обратная крайность: человек, который всё инициирует и всё делает сам. Поднял вопрос - сам решает. Увидел проблему - сам чинит. Предложил направление - сам тянет.

Это не лидерство. Это героизм в одиночку, и он заканчивается предсказуемо: выгоранием, зависимостью команды от одного человека и — снова — ловушкой незаменимости, только теперь уже добровольной.

Настоящий IC-лидер делает две вещи одновременно. Он инициирует - и выстраивает систему, в которой другие тоже могут инициировать. Он мотивирует, созидает, делегирует с пониманием. Не потому что "должен по роли", а потому что понимает: его задача - не сделать самому, а сделать так, чтобы это происходило без него.

Херси и Бланшар в модели Situational Leadership ^[6] показали, что эффективный лидер адаптирует стиль под зрелость команды. Молодому джуниор-разработчику нужны чёткие инструкции. Опытному сеньору - пространство и доверие. Давить своей экспертизой одинаково на всех — значит тормозить одних и демотивировать других.

Где это работает — и где нет

Всё описанное выше про продуктовые, рыночно-конкурентные компании. Там система вынуждена вознаграждать тех, кто реально создаёт ценность, иначе проигрывает. Пользователь голосует деньгами и вниманием. Метрики видны всем. Плохое решение даёт обратную связь быстро.

В государственных структурах и окологосударственных организациях механика принципиально другая. Там карьера строится не через ownership и craft, а через лояльность и близость к принимающим решения. Не потому что люди там плохие, а потому что системе не нужна рыночная обратная связь. Некому проголосовать против плохого продукта. Значит, метрика успеха — не ценность для пользователя, а ценность для вышестоящего. Это не продуктовый подход. Это другая игра с другими правилами.

Если вы работаете в такой системе и чувствуете, что механика не совпадает с тем, что описано в этой статье, то, возможно, дело не в вас. Иногда правильный ответ не "измени себя", а "измени систему", в которой ты работаешь.

Что делать практически

Формула простая: не останавливаться расти в экспертизе — и одновременно инициировать что-то за пределами своих задач. Не вместо, а поверх. Это не подвиг и не революция. Это один дополнительный шаг, который меняет то, как тебя воспринимают.

Конкретно по ролям:

Разработчик. Продолжай углубляться в стек: архитектура, производительность, новые инструменты. Но возьми ownership над чем-то, что выходит за рамки твоих задач. Например — стань ответственным за надёжность системы в целом: SLO, алерты, постмортемы. Или возьми под крыло скорость загрузки с точки зрения UX — собери метрики, предложи план, веди его. Это не про "делать больше работы". Это про то, чтобы у тебя была своя повестка, которую ты сам же и сформулировал.

Аналитик. Продолжай проводить исследования в своей команде, копай глубже в данные, строй модели. И одновременно — предложи курировать межкомандное исследование. Например, если три команды параллельно изучают retention, а результаты нигде не сходятся — именно ты можешь стать человеком, который это видит и структурирует. Это сразу другой масштаб видимости и другой разговор с менеджментом.

Дизайнер. Делай текущие макеты хорошо — это основа. Но возьмись за сквозное UX-исследование, которое никто не курирует: как пользователь движется между несколькими продуктами или фичами разных команд. Такие вещи обычно никому не принадлежат — именно поэтому там есть место для человека с инициативой. Ты перестаёшь быть "дизайнером своего экрана" и становишься человеком, который видит продукт целиком.

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

В конце — снова про коня

Колхозный конь не виноват. Он делал ровно то, чему его научили. Пахал. Хорошо пахал. Если бы он не умел пахать, то он бы вообще не работал в колхозе.

Но если бы вместо коня был IC, он бы не просто пахал поле. Он бы посмотрел на поле и спросил: а почему мы пашем именно так? Почему этим инструментом? Почему в таком порядке? Он бы попробовал по-другому, ошибся, попробовал снова. Но продолжал бы пахать и созидать. Придумал борону, потом плуг, потом в какой-то момент паровой двигатель. И так постепенно конь становится менеджером.

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

Джобс был прав. Абсолютно прав. Мир меняют не те, кто хорошо исполняет чужие задачи, а те, кто ставит свои. Вопрос не в том, чтобы работать хуже или перестать быть экспертом. Вопрос в том, осознанно ли вы выбираете, чью систему оптимизируете.

Незаменимых не повышают. Но тех, кто строит свою повестку, замечают.