Зачем и как избавляться от незаменимых сотрудников

• Дублирование знаний

«Маша, тебе Роман объяснял, как пользоваться системой? Отлично, напиши, пожалуйста, на Wiki статью и дай Роману проревьюить». Оцифровка знаний через дубляж с помощью других коллег, наверное, самый идеальный способ работы при незаменимых сотрудниках. 

Прям с ходу могу сказать - это 95% будет статья написанная левой пяткой, а Маша через 2 недели без практики забудет, что она писала... Управленческий ритуал выполнен, а ничего не поменялось...

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

Видимо должно работать только со штрафом в пол зарплаты за минутное опоздание...

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

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

Иван, спасибо за статью. Но вы описали идеальную команду в идеальном мире, где все хотят знаний, читают инструкции и горят развитием. На практике же 80% людей приходят на работу потому что кушать надо. Им фиолетово на ваши ротации и дубляж знаний. Они хотят получить задачу, сделать, получить деньги, пойти домой. И да, они не читают инструкции. Никогда. Потому что проще спросить у того, кто знает. А те 20%, кому интересно, развиваются сами, копают глубже, становятся незаменимыми и потом читают статьи про то, как от них избавляться. Методы из статьи хороши ровно до первого контакта с реальностью, где у человека есть жизнь кроме работы. Проблема не в том, как передать знания. Проблема в том, как заставить их забрать.

Конечно, все правильно. Все процессы должны быть структурированы и прозрачны и не должно быть уникальностей.

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

К чему это я? К тому что в сложной системе хочется знать про все и понимать как это работает, но иногда определенная голова про это помнит лучше чем другие. Спасибо, что написали не обтекаемо, а точно. Теперь лично у меня не будет возникать вопросов к вашему облаку. Спасибо.

"«Роман, ты сделал такую классную тестовую систему! А напиши всё-таки документацию, как ей пользоваться, чтобы другие могли её запускать и не отвлекать тебя» " - тут автор оговорочку забыл приписать, зачастую такие просьбы не входят в рабочее время, как бы просят в не рабочее время написать мануал. В чем собственно проблема сделать СТО задачу с наивысшим приоритетом и мануал будет готов! Лукавишь автор!

В целом "рыба гниет с головы!". Какой СТО был в команде, такой и результат на выходе. Не надо, как говорится, перекладывать на незаменимых сотрудников.

Можно ли написать документацию, прочитав которую джуниор начнёт локализовывать баги в незнакомом коде так же быстро, как Фёдор?

Отчасти согласен с автором, что наличие незаменимого специалиста в команде несет риски для команды. Но хотелось бы описать ситуацию и с другой стороны, со стороны такого незаменимого специалиста.
Я на одном из этапов своей карьеры был тем самым незаменимым специалистом и вот какие отрицательные моменты для меня это несло:
1) В рабочее время ты в основном решаешь чьи-то проблемы, объясняешь, почему это не работает, или работает не так, поскольку кроме тебя это никто не знает - и почти совсем не решаешь свои рабочие вопросы или же решаешь их в послерабочее время
2) Почти нет свободного времени - в выходные и вечером тебе могут позвонить потому что что-то где-то упало и надо либо срочно выезжать либо чинить по удаленке. Я почти 3 года не мог сходить в отпуск нормально по этой причине - максимум на неделю и чтобы был всегда на связи.
3) Я был бы рад поделиться знаниями, но на тот момент либо никого не было, кому эти знания передать, либо не было времени, чтобы это все хорошо задокументировать - хорошо, что на память я в то время не жаловался.
В определенный момент меня это все достало и я пошел к руководству и сказал, что я не вывожу это в одного и мне нужен помощник. Помощник появился через какое-то время и я, введя его в общий курс дел и поделившись с ним теми самыми недоступными никому знаниями, отправил его в свободное плавание, делегировав ему часть своих задач. Первое время он обращался ко мне несколько раз в день, но со временем кол-во обращений снизилось до 1-2 в неделю. Ситуация через какое-то время повторилась со вторым сотрудником, у нас наконец-то появилась возможность это все задокументировать хоть как-то и еще через год после всего этого я смог наконец-то уехать в отпуск на 2 недели и никто не звонил мне во время отпуска. И когда я через несколько лет уволился, то я четко знал, что все что я знал - оно не осталось только у меня, есть люди, которые смогут справиться с теми задачами, которые решал я, когда был незаменимым.

-- У нас проблема. У нас талантливый сотрудник (я ему, конечно, об этом на 1:1 не говорю, чтобы нос не задирал), который имеет больше effort points в спринте, чем все остальные, вместе взятые. Он всегда вызывается помочь и все самые сложные задачи, которые я ему поручал, он решал.

-- А в чем проблема-то?

-- Он демотивирует остальных. Я хочу от него избавиться.

-- Логично.

Не только увольнение: способы избавиться от незаменимых сотрудников

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

Прозвучало как сожаление о том, что такой метед “решения” редко прокатывает и не является единственным возможным. Без шуток осталось слегка гаденькое чувство после прочтения. Проблема рассматривается как игра с нулевой суммой между худшим случаем незаменимого специалиста (коллекционер тайных знаний - саботажник) и его калькой из мира управленцев (могу управлять чем угодно, ничего не понимая в прцессах - просто построю систему из одинаковых взимозаменяемых винтиков, выкинув или подрихтовав кувалдой все “выдающееся”). Оптимистично предположу что это вышло, пардон, по глупости (думаю на хабре технарей больше чем управленцев), а не со зла в силу склада мышления автора или ожидаемой ЦА в виде вышеназванного подвида управленцев.

“Кабы я была царица” то, помимо разделения незаменимых сотрудников по категориям, прошелся бы по мотивации этих сотрудников и попытался спроектировать взаимовыгодное решение проблемы незаменимости. В том числе с осознанием того факта, что в большинстве случаев для незаменимого сотрудника это не является, или не осознается, проблемой. Типа такого (чуть упростив Вашу классификацию) .

Хайперформер. С большой вероятностью или не осознает свою незаменимость, или не считает это своей, а не управленца, проблемой. Грубо говоря, он искренне готов всегда поделиться опытом, но либо не может “залезть в шкуру” лоуперформера, чтобы обьянить так чтобы тот понял, либо ему это неинтересно. Предложить (в крайнем случае придумать) другую, не менее интересную, задачу “здесь никто кроме тебя не справится” с выделением в помощь при решении его текущей задачи “перенимателей опыта”. Вот тогда он будет заинтересован в выстраивании процесса передачи опыта по “старой” задаче. И да, “просто отправьте его на конференцию” врядли сработает - такие люди не так глупы, и не всегде настолько тшеславны или аутисты, как о них думает средний управлец на основании того, что в бюрократические игры они играют хуже него (они им просто неинтересны).

Добросовестный тащун - лучше сделаю сам, чем играть в бюрократический пинг-понг по делигированию и выстраиванию процессов. Тут еще проще - он и сам бы рад поделится знаниями, но не за счет “классно ты работаешь за себя и за раздолбая Петю, давай ты еще и будешь Пете квалификацию повышать == взвалишь на себя задачу раздолбая менеджера Феди”. И все это при сохренении прежней нагрузки и зп. Т.е. тут не сотрудник проблема, а хреновый менеджмент.

Саботажник. Ну вот тут примерно по мотивам Вашей менеджерской методички, только начав заход по лекалам добросовестного тащуна - “ты такой классный, давай мы тебя чуть разгрузим/повысим”, отслеживая насколько получается выстроить передачу опыта, т.к. может оказаться что это не саботаж, а неумение в общение или околоменеджерские задачи. Ну или чтобы не спугнуть, если таки худший случай.

Странно, что у статьи так много плюсов, хотя очевидно, что вся статья - это отрыжка ИИ.

Мы в коллективе приняли логичное решение «А давайте наконец сдвинем дату релиза!». Но тут меня остановила команда: «Стоять, завтра к нам подключится Федя».

Подскажи, как такое может быть, что "Мы в коллективе приняли решение, но при этом коллектив с тобой не согласен и всячески тебя останавливает"?

Этот "коллектив" он сейчас с нами? В этой комнате? Или он существует только в твоей фантазии?

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

Каким образом у закрытого проекта имеются какие-либо заказчики? Проект ведь закрыт, а значит, он никому не нужен. Почему проект закрыли, можешь уточнить у руководителей отдела или департамента. Они владеют нужной информацией.

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

Сделали сборку, запустили, баг починили, заказчик счастлив, команда счастлива. Несчастлив менеджер.

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

Какой менеджер несчастлив? Менеджер, который уволился 3 года назад из закрытого проекта? Или менеджер - это ты? Если ты, то какое отношение ты имеешь к этому мёртвому проекту, где нет ни команды, ни менеджера? Если этот мёртвый проект отдали тебе, то именно ты должен возродить команду, правильно настроить процессы в нём и стать счастливым. Или ты ждёшь, что кто-то сделает тебя счастливым?

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

bus factor - это проблема руководителя, а не сотрудника.

Шутка прям так и напрашивается, но это не пикабу)

(предлагаю на этом и остановиться)

Попытка сделать всех одинаково некомпетентными в максимально широком спектре технологий - очень частый менеджерский паттерн, рационализируемый идеей, что можно будет таки сделать тот самый мифический человеко-час реальным. И тогда занимаясь любимой менеджерской штурмовщиной перед очередным рандомно запланированным дедлайном тестер Ирина при авральном релизе будет править CSS вместе с бэкэндером Сергеем. Интересно, кто-то пробовал донести до менагерков выгоды разделения труда и специализации. Понимают?

У нас нынче в тренде расчеловечивание?

За всеми правильными словами про bus factor и ротацию ни разу не мелькнула мысль о том, каково это быть Федей. Человек блин годами тащил на себе критические куски системы, спасал релизы, а в итоге оказывается не коллегой, а организационным риском, который надо «нейтрализовать». Финиш: аналогия с женой, которую отправляют варить борщ, чтобы не мешала. Ну и «в сложный период ушло 40% сотрудников, но мы не сорвали ни одного релиза» это успех? У вас блин 40% текучки, если только для красного словца вы не говорите, что это 2 из 5. Если 4 из 10, это нифига не норма, от вас тупо сбежали. Люди ушли, похрен, зато дедлайны соблюли.

Должен остаться один ("Горец")

Вечная борьба менеджеров с незаменимыми...

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

Всегда уходя оставлял доки и в файлах и в распечатках. По мере возможности дополнял железом и инструментом, хотя-бы на первое время.

Всегда (блин) железо приватизировалось, а по докам чаще или выбрасывалось или просто файлы стирались. Им оказывалось проще позвонить и спросить что, где и как, а то вообще "может по старой памяти всё сделаете сами".

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

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

Добавлю в закладки из-за комментов, ну неплохой the worst practice

Покрутил в голове с точки зрения стратегии и опыта: крупных корпорациям не сильно нужны перформеры и рыцари на белом коне, условный мидл и синьер , которые приходит и с 10 до 19, с перерывами часовыми на обед и кикер, - вполне себе нормально делают свою работу, для буйных перформеров обычно в таких компаниях есть r&d или внутренний инкубатор, где среди таких же можно отрываться. Но про процессы всё равно не нужно забывать и про их эффективность, а так же работоспособность в реальной цейтнот ситуации.

В статье показан пример, как дефективный манагер разваливает фирму/проект и наивно полагает,что виноваты незаменимые. При этом с самого начала на примере сроков задачи конкретно этот дефективный НЕ провел анализ рисков, реальных (!) сроков, анализ компетенций и загруженности сотрудников.

Далее, на примере Руси незаменимый документирует для Джуна: миддл или сеньор работает со своим уровнем знаний и опыта. При этом дефективный манагер Обязан организовать обучение для тех, кто по его мнению отстаёт в компетенцию и развитии. И это требует денег, времени и как ни странно работы с персоналом.

Но,к сожалению полно дефективных , которые видят только показатели, не отражающие весь производственный цикл со всеми трудоемкости и проблемами. Как итог малоэффективной производство , постоянная ротация персонала. А с учётом требований нового поколения - отсутствие нужных кадров.

Адиос

В IT — 20 c копейками лет. Потрудился в восьми компаниях, в пяти из них управлял отделами.

Не обязательно относится к автору статьи, но почему то навеяло.

Типаж - кочующий менеджер. Знаю. сталкивался. Зачастую даже дают очень хорошую характеристику лишь бы ушел поскорее (увольнение по своему желанию) куда ни будь в другое место. Сем видел несколько таких примеров (впрочем и с программерами то же).

При этом частое смена работы по причине (по словам) “стало не интересно там. не те масштабы”. Но по факту, обычно пол года дают на вхождение в тему, год на “ну может быть получше будет. отчеты же хорошие”. А потом просто сваливает в другое место.

Основное чем оперирует - трудоднями и красивыми отчетами для начальства.

До сих пор помню как “преподаватель” на курсах PME рассказывал, что настоящему менеджеру проектов все равно чем управлять “хоть созданием космического кОробля, хоть стройкой дома” (сейчас не можно, но как то занесло и получил сертификат)

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

А по факту 5 раз избавлялись от автора. Оно и понятно - фраза "давайте сольём ценный актив" - это уже повод проверить вышестоящему руководству, а "я вам потом расскажу зачем" - ну, в принципе, можно и не проверять.

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

Спасибо

>к теории ограничений Голдратта

Творчество Голдратта - это шарлатанство типа ТРИЗ или саентологии. Даже странно, что в 2026 году его продолжают упоминать.

Статья из разряда. Много букв в свое оправдание. На самом деле автора статьи до управления командами вообще допускать нельзя. Вот того незаменимого для примера , обучения и вдохновения команды нужно поставить. А автора в гаражи на сборку мебели механическим путем определить. Такие статьи к развалу отраслей и команд приведут.

Погодите-погодите! А решение точно бьется с проблемой?

Возьмем ваш пример с Федей. Вот видно, что до дедлайна не успеть.

Как было: подключали Федю и успевали.

Как стало: Не подключаем Федю а.... что? Ротируем Федю? Заставляем Федю писать вики? Заставляем Федю передать знания Маши?

Что заставляет думать, что при таком подходе мы не сорвем этот (и последующие) дедлайны?

В IT — 20 c копейками лет. Потрудился в восьми компаниях, в пяти из них управлял отделами

2.5 года в компании? Прилетел, нагадил, улетел называется 😁 Федя таких как вы 3-4 видел уже за время работы в компании, а ему потом ещё после таких эффективных разгребать. И времени промоутить себя любимого статьями про успешные кейсы у него тоже нет. Да и зачем, если у Федора уже есть кардинальное решение - early retirement, а все остальное просто шум.

Ахахах - менеджер не счастлив... Правильно выше написали - пришёл "эффективный" менеджер (директор/руководитель) - уволил "Федю", а через годик и сам ушел за ЗП повыше и всё...

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

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

Привет от такого сотрудника. А дальше немного из опыта:

Мне не понравилось отношение команд ко всему этому.

Ну тут нашли проблему ура, потому что сделаем? “Уволим” сотрудника. Логично же.

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

Ну это не совсем так. Есть небольшой “секрет” в высокой производительности это … лень. Вот лениво возвращаться к этому постоянно, потому ты сядешь, разберёшься, потратишь достаточно времени и сделаешь так, чтобы оно больше не заваливалось (в граничных случаях, чтоб чинилось само). И оно будет продолжать работать спустя долгое время. И да, так как ты к этому тоже возвращаешься редко ты и для себя оставляешь комменты, чтобы вернуться в контекст (тут же не надо слово объяснять?) И после ухода оно будет продолжать работать достаточно продолжительное время, чтоб следующий человек разобрался.

вы просто не можете производить продукт быстрее, чем работает ваш самый продуктивный сотрудник, он задаёт верхнюю планку.

Ээээ я правильно понял, что тут либо 1) вы будете выжимать из других соки, чтобы они начали из себя рвать жилы чтоб перепрыгнуть одобренное вами новое горлышко, либо 2) “поувольняете” всех пока не дойдёте до приемлемого_для_вас/определённого_вами перформанса?

Риск потери контроля над незаменимым сотрудником и командой. Например, если такой сотрудник будет действовать по своему усмотрению, а не плану, согласованному с продакт-менеджером.

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

А давайте мы перестанем оставлять баги на этап стабилизации и начнём их чинить по мере возникновения

Ну то есть всё же проблема действительно в команде, а не в Феде, да? Но не будем идти против логики и “уволим” Федю.

Как это ни смешно, но вопросы о качестве работ возникают именно к незаменимым сотрудникам. Осознание того, что вы являетесь единственным владельцем какой-то зоны ответственности, не стимулирует вас писать документацию, делать «защиту от дурака». Если вы хоть раз заглядывали в код уволившегося сотрудника с фразой: «Да боже мой, как эта фигня работает?», знайте, скорее всего, он считал себя незаменимым.

Это наверное не случай номер 1 (High-performance-сотрудники). Именно по вытекающему из написанного выше - будешь делать так, чтоб оно работало долго, потому что ты сел и разобрался.

А напиши всё-таки документацию, как ей пользоваться, чтобы другие могли её запускать и не отвлекать тебя

а её никто не читает, быстрей выбить сотрудника из контекста - ведь ему починить “5 минут”, и “менеджер” никогда в жизни не научит команду так не делать, зато может научить этот самый сотрудник (у этого тоже есть минусы)

Давай через полчаса соберём всю команду, и ты покажешь, как решишь новый

А не работает так. Почему - по времени ты решил двухневный баг за полчаса. А в общем ты увидел его пару дней назад и подсветил, в течение всего этого времени ты мимолётно в голове возвращаешься к нему крутя и так и эдак (да скорее всего не дольше минуты просто отдыхая от другой задачи), возможно у тебя ещё появляются сторонние идеи и ты уходишь в них. В итоге разобравшись со всякой ерундой ты берёшь и правишь его за 30 минут. Если в течение этих 30 минут у тебя будут сидеть нцать человек над душой и параллельно задавать вопросы в виде “а зачем ты такую фигню ищешь, ты_её_не_знаешь/она_к_этому_не_относится” это будет дольше 30 минут и больше нервов сожжено параллельно.

А почему вы начинаете просто так ротировать людей, которые делали что-то и, наверное, знают лучше

А вот почему мы не хотим всех тянуть к верху, а приблизить к низу.

немножечко отстранить перформеров от операционной деятельности.

Дык перформерам и так это неинтересно и по больше части они давно самое простое или спихнули с пинками на других или автоматизировали.

Менторство

Это прям моё любимое, я давно перестал кого-то учить и подтягивать (исключение - давно работающие). Вот прям 100% случаев, ты его/её прокачиваешь и он/а через пол года уходит на большие деньги :)

Если у перформера есть потенциал для роста, вы можете собрать под него мини-команду.

На практике я такого не встречал, обычно “нет денег”. А потому часть фигни ты уже сам передаёшь с инструкцией кому-то попроще.

Все новые методики учат тому, что нужно начать с разговоров с сотрудниками и объяснения наших целей.

Ты работаешь слишком хорошо и мне неуютно, а потому мы тебя “увольняем”

Поставьте цель на следующие полгода, чтобы он передал свои знания, навыки

Эххх я по пальцам могу пересчитать кому было бы интересно поковыряться в чём-то и разобраться в причинах вместо того чтоб выполнять простое “если горит А нажми первую кнопку, если 1, нажми вторую. Главное не перепутай”. А потому даже рассказав голую теорию, через 5 минут она вылетит

В сложный период компании у меня из отдела ушло 40% сотрудников сейчас работаю в Yandex Infrastructure

Ок, понял.

Объединяя сказанное выше - как по мне вы хорошо так всё смешали пытаясь выстроить в единую структуру. Даже так скажу, не считаю себя незаменимым, вопрос в том сколько времени потратится на замену и работу для достижения такого же результата. Кстати с опыта управления - ты просто будешь использовать и рассчитывать по человеку. Если знаешь что у первого на задачу уйдёт три дня, у второго один, но при этом есть критическая штука, которую надо бы сделать, то назовёшь срок 5 дней и отправишь второго чинить критическую, а первого на задачу. Хотя способ “выгнать” второго, пригласить третьего и четвёртого на задачу, а первого отправить чинить критическую штуку я не пробовал, возможно он хороший по крайней мере он чётко коррелирует с логикой выше.

Господи, какой наивный бред. И самое печальное, что большинство эффективных руководителей именно так и думают, когда все ломают. Он уберёт всех незаменимых и все станет супер. Остальные.. сразу подтянуться и станут разбираться во всем, что тащил этот трудолюбивый? Ну конечно!

Иван, Вы вообще где кем работали то?! Прям интересно.

Оно само. Например, если после краха отдела остался единственный сотрудник

Крах отдела - это эвфемизм на сокращения?

В сложный период компании у меня из отдела ушло 40% сотрудников

Ага, надо почаще уходить из отделов 40% сотрудников, это очень способствует тому, чтобы знания не концентрировались в отдельных головах, да.

Едой не корми дай процессы подправить.

Долой незаменимых сотрудников, начинать будем со сверхпродуктивных.

Попробовали — работает. Сделали сборку, запустили, баг починили, заказчик счастлив, команда счастлива. Несчастлив менеджер. 

Вся работа коту под хвост!

Уххх наболело. Как раз в соло сделал прототип. Потом дали разработчика и запилили MVP. Теперь дали зелёный свет на полноценный продукт. Вот только разработка стоит с момента запуска AB теста. А в ML модельку простая фича добавляется 4 месяца. У меня ещё глаза горят, а у крутого разраба стали тухнуть. Дали ему пилить интересный прототип нового продукта в формате пет проекта в свободное от основной загрузки время.

Я честно не понимаю, где проблема с документацией после появления LLM.

Заставьте людей работать в паре хотя бы по часу в день и этого будет достаточно. Не будет незаменимых, TTM уменьшится, качество решений и вовлеченность сотрудников увеличится.

Доку и требования разрабы не читают. Недавно массово натравил LLM на PR. В 70% была пропущен часть пунктов из задачи или сделано то, чего не просили Пользователи не читают подавно. Им лучше видео записывать

Конечно зависит от формата. Если вам надо заонбордить 50 человек за короткий срок, то логично написать доку и видео по онбордингу. Но всё равно лучше прикрепить к каждому наставника, который будет отвечать на вопросы первые 2-6 недель.

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

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

Вы совершенно игнорируете тот факт, что это команда поощряет Федю приходить и разгребать за ними. Это команда не хочет решать проблемы. Как минимум, они должны были прийти к Феде и опросить его, чтобы составить документацию, если её недостаточно. Вместо того, чтобы увеличивать активность и ответственность команды, вы предлагаете, например, нагрузить Федю задачами по уточнению документации. А остальная команда чем будет заниматься в это время? Ок, про Федю мы знаем: он проектирует, программирует, разгребает за командой. А теперь вы ему накидываете ещё приключений: составить документацию, обучить команду. Я вам подскажу: надо ему ещё фару на лоб, чтобы он всё это ночью делал.

Типичная ошибка начинающего ПМ или HR - искать проблему не там, где она кроется. Бороться с ветряными мельницами. Описанная вами команда - ленивая и безответственная. Она не хочет разбираться с проблемой. Руководители не поощряют рост команды. Единственным правильным методом здесь было бы отложить релиз и вообще не подключать Федю. Команда должна была сама решить свою проблему. А Федю надо было повысить в должности. До какого-нибудь техлида, которому было бы запрещено программировать - это, кстати, ещё одна распространённая проблема - совмещение ролей. Ваши причины появления незаменимого человека можно свести к простому пункту: очень плохие процессы в команде. Мне довелось побыть таким незаменимым человеком не раз. И я могу сказать точно: если в команде отлажены рабочие процессы, ты не будешь незаменимым. Когда кто-то начинает оптимизировать эти процессы, или их попросту нет, или они сломаны, тогда начинает проявляться разница между людьми, которые работают эффективно и неэффективно. Отлаженный рабочий процесс ограничивает эффективность как сверху, так и снизу. Нельзя работать плохо. Ты не можешь сдать работу, если она не задокументирована. Ты не можешь сдать работу, если нет тестов. С другой стороны, тебе не разрешается работать по 16 часов, чтобы соблюсти дебильные сроки. Это выравнивает производительность и эффективность команды. А бороться с Фёдорами - это как лечить только симптомы. Вы уволите первого Фёдора, либо допустите, чтобы он выгорел. Завтра руководитель наймёт ещё одного Фёдора, чтобы тот ему работал за троих. Вы опять от него избавитесь, но руководителю нужно, чтобы вы не переносили сроки релиза, а для этого ему нужен Фёдор, а не вы. И, знаете, он в этом прав: Фёдор, хотя бы, честно делает свою работу. А вы даже не можете дисциплинировать команду. Зато, пишете статьи на Хабре о том как бороться с эффективными сотрудниками. У Высоцкого такая песня есть: Случай на Шахте, в которой шахтёры отказались раскапывать заваленного в штреке стахановца, чтобы их не заставляли на него ровняться. У вас примерно та же история: неэффективный менеджер пишет статью о том, как он борется с эффективными сотрудниками. Не лучше ли бороться с собственной неэффективностью?

З.Ы. Сотрудники имеют свойство профессионального роста. Если у вас в команде появился Федя, то, скорее-всего, он перерос свою должность. Есть люди, навыки и умения которых выше, чем предполагает их текущее место работы. Они получают не свою зарплату, но не могут устроиться в более топовую фирму по тем или иным причинам. Самое банальное - состояние здоровья. Семейные обстоятельства. Или нет времени преодолеть барьер подготовки к интервью в более крупную компанию. Например, нет навыка решения Литкода. Или нет углублённых знаний баз данных. Здесь, наверное, можно сказать, что увольнение - это самый разумный шаг. Потому, что нагружать человека документацией, онбордингом, менторством, когда он уже нагружен руководителем задачами по разработке - это свинство. Проще признать, что ваша компания не готова развиваться. Что ваша команда разработки - бесполезная. Что Фёдору нечего ловить с вами. Вы катитесь по наклонной, а его ждут лучшие компании. Лучшие люди. Должно быть, да, увольнение Фёдора - самый лучший способ для вашего работодателя совершить каминг-аут и признать очевидное: вы ничего не хотите менять внутри себя. Вам нужна внешняя причина ваших узких горлышек.

Теперь понятно, почему в yandex не берут возрастных сеньоров - боятся незаменимых специалистов ;)