Привет, Хабр! Я — Иван Потапенко, на момент подготовки этого материала был независимым экспертом, а сейчас работаю в Yandex Infrastructure. В IT — 20 c копейками лет. Потрудился в восьми компаниях, в пяти из них управлял отделами. Эта статья основана на докладе для конференции Saint TeamLead, и в ней я расскажу о том, что делать, если некоторые процессы в команде сильно завязаны на отдельно взятых людях.
Зачастую есть план «Б». Я большой фанат планов B, C, D — не в том смысле, что мне нравится, когда всё идёт по плану Е, Ё и другим буквам. Мне так спокойнее, я могу делать более резкие движения, более рискованные шаги, что даёт свой положительный результат. Поэтому мне хочется рассказать, почему следует избавиться от всех незаменимых сотрудников в ваших отделах, как это сделать легко, а порой даже с удовольствием.
Кто такие незаменимые сотрудники: на реальных примерах
Недавно мне посчастливилось участвовать в стабилизации одного релиза. До него оставалось дней пять, и в проекте было порядка 60 багов. Продукт для меня новый, команда тоже, логичен диалог: «Ребята, а мы точно справимся?» — «Фигня вопрос», — отвечает команда, и мы стартуем.
В первый день команда закрывает 15 задач — классно, даёт надежду на успех. Но вечером приходит QA, переоткрывает 4 и находит 10 новых. Ладно, в принципе, по закону больших чисел мы все знаем, что одно измерение — не показатель. Однако ситуация повторяется.
Мы в коллективе приняли логичное решение: «А давайте наконец сдвинем дату релиза!». Судя по графику, примерно через три месяца мы могли стартовать без проблем, но тут меня остановила команда: «Стоять, завтра к нам подключится Федя».
Фёдор — эксперт компании, написал много кода в различных продуктах, и с его участием ситуация стала немного лучше.
Мы вовремя всё стабилизировали и выпустили релиз. Казалось бы, успех! Но в течение месяца я становлюсь свидетелем похожей ситуации с другой командой.
Проблема заключалась в одном из проектов, который закрыли три года назад. Команда уже распалась, большая часть сотрудников уволилась. Но появился заказчик, который говорит, что на каком-то устройстве при определённых условиях возникает баг.
Начали проводить сборку, а она не запускается. Что делать? Стали искать людей, которые занимались этим проектом и нашли того, кто знает именно это устройство и его специфику. Диалог выглядел приблизительно так.
Попробовали — работает. Сделали сборку, запустили, баг починили, заказчик счастлив, команда счастлива. Несчастлив менеджер.
В этих ситуациях меня стриггерил даже не факт наличия сотрудников, которые могут точечно решить проблему. Мне не понравилось отношение команд ко всему этому. Вкратце его можно описать так: «Классно, что у нас есть такие люди, иначе бы всё накрылось медным тазом!». В целом, они правы, и именно таких людей я называю незаменимыми сотрудниками.
По сути, это люди, которые обладают чем-то уникальным — знанием, навыками, либо ресурсами, которые позволяют им решать задачи, неразрешимые для других. Иногда это лучшие сотрудники отдела, как в первой ситуации. А иногда случайные люди, которые обладают знаниями или специфичными ресурсами.
Перед тем как рассказать, зачем всё-таки надо избавляться от людей, на которых держится всё, мне хочется подсветить, откуда же появляются у нас такие сотрудники.
Причины, по которым в команде появляется незаменимый сотрудник
Я выделяю три решающих фактора:
High-performance-сотрудники — те, которые изначально обладают незаурядными навыками и знаниями. Продуктивность этих специалистов кратно превышает продуктивность любого другого сотрудника, а порой даже отдела целиком.
Оно само. Например, если после краха отдела остался единственный сотрудник и так получилось, что все знания о продукте, навыки работы с ним или другой ресурс остались только у него. Проблема в том, что, в отличие от перформеров, этот сотрудник не обязательно сверхпродуктивный и незаурядный, зачастую это просто типичный миддл.
Процессы и традиции — такой человек появился в команде специально. Лично я считаю этот фактор едва ли не основным. Например, если компания перестанет требовать от сотрудника «тратить время» на составление инструкции к новым фичам, полагаясь на то, что он создаёт рабочий продукт и наверняка продолжит это делать, то со временем каждый такой сотрудник станет обладателем уникальных знаний и будет незаменимым. Именно поэтому я считаю, что процессы — это самый простой способ создать себе проблемы на пустом месте.
Риски, связанные с незаменимыми сотрудниками
Казалось бы, зачем избавляться от незаменимых сотрудников, если они хорошо решают сложные задачи. Но я считаю, что у этого есть негативные последствия:
В ближайшее время вы провалите один из своих проектов.
Постепенно начнётся деградация процессов.
Развитие других ваших сотрудников остановится.
Риски для производительности
Почему вы провалите проект?
Bus-Factor
Потеря сотрудника из-за болезни или увольнения вычёркивает большую часть экспертизы из вашего отдела, что ставит любой проект под риск.Bottleneck
Обращаясь к теории ограничений Голдратта, это бутылочное горлышко: вы просто не можете производить продукт быстрее, чем работает ваш самый продуктивный сотрудник, он задаёт верхнюю планку.Саботаж
Риск потери контроля над незаменимым сотрудником и командой. Например, если такой сотрудник будет действовать по своему усмотрению, а не плану, согласованному с продакт-менеджером.
У всех этих рисков есть одна положительная сторона — они произойдут не сразу и не обязательно в ближайший месяц. Однако негативное влияние незаменимых сотрудников будет всегда давить на ваши команды.
Негативное влияние незаменимых сотрудников на команду
Централизация профессионального роста
Персональный рост остальных сотрудников ограничен, потому что им не поручают сложные задачи. Наверняка в условиях ограниченного времени вы отдадите критически важную или самую интересную фичу самому производительному сотруднику. Все остальные участники команды так и остаются на заурядных задачках и постепенно деградируют.Слепота к точкам роста и деградация процессов
Люди просто не замечают, что процессы в команде работают не всегда правильно, ведь у вас есть рыцарь на белом коне, который приходит и всё спасает. Решение первой истории с Федей было до ужаса тривиальным: «А давайте мы перестанем оставлять баги на этап стабилизации и начнём их чинить по мере возникновения». И это сработало, но изначально команда просто не видела это — все последние релизы она закрывала без проблем, и никто не страдал. Только нервные клетки руководителя.Вопросы к качеству работ
Как это ни смешно, но вопросы о качестве работ возникают именно к незаменимым сотрудникам. Осознание того, что вы являетесь единственным владельцем какой-то зоны ответственности, не стимулирует вас писать документацию, делать «защиту от дурака». Если вы хоть раз заглядывали в код уволившегося сотрудника с фразой: «Да боже мой, как эта фигня работает?», знайте, скорее всего, он считал себя незаменимым. По крайней мере, в этой части.
Быть незаменимым — это палка о двух концах
Незаменимые тоже платят свою цену:
Перегруженность
Сотрудник вынужден раз за разом уделять внимание той области, в которой он незаменим, отрываясь от текущей работы, и тратит всё больше времени на саппорт вместо создания новых фич.Проблемы с промоушеном
Для промоушена такого сотрудника потребуется найти замену на его обязанности, а он незаменим.Затруднено саморазвитие
При высокой перегруженности сотрудник ограничивается деятельностью в той области, в которой он является незаменимым, и постепеноо начинает деградировать. Просто потому, что некогда изучать новый материал либо негде его применить.
Так зачем избавляться от таких сотрудников?
Для CTO я обычно продаю первые три проблемы с производительностью — и этого достаточно. В случае с командой идеально работают последние три проблемы. А для себя я решил: если я хочу работать в команде, которая развивается органично и постоянно добивается новых результатов, то просто должен избавиться от незаменимых сотрудников и растить всех равномерно.
Не только увольнение: способы избавиться от незаменимых сотрудников
Увольнение не всегда является решением — более того, скорее всего, вам не одобрят предложение избавиться от самого лучшего сотрудника в отделе.
Ранее я сказал про три уникальных фактора, которые делают людей незаменимыми: знания, навыки и ресурсы. По сути, если мы сделаем их неуникальными, этого должно хватить.
Пойдём от простого к сложному.
Оцифровка знаний
Достаточно просто оцифровать знания.
Есть куча методик, которые рассказывают, что такое знания, как они формируются, что такое неявные и явные знания, как они переходят друг в друга.
Здесь хочу подсветить два метода, которые пригодятся в работе с незаменимыми сотрудниками. Часто это идёт по такому сценарию: «Роман, ты сделал такую классную тестовую систему! А напиши всё-таки документацию, как ей пользоваться, чтобы другие могли её запускать и не отвлекать тебя». А через неделю человек говорит: «Я был так занят! Ко мне прилетели более важные новые задачи, поэтому документации нет». В принципе да, незаменимые сотрудники более загружены, в это можно поверить, если бы не одно НО. Как правило, за эту неделю Роман делает 4–5 созвонов с другими командами, рассказывая, как пользоваться этой системой, либо помогая запустить тесты, а это похоже на саботаж.
Но есть выход:
Дублирование знаний
«Маша, тебе Роман объяснял, как пользоваться системой? Отлично, напиши, пожалуйста, на Wiki статью и дай Роману проревьюить». Оцифровка знаний через дубляж с помощью других коллег, наверное, самый идеальный способ работы при незаменимых сотрудниках.
Работа вслух
Этот метод направлен не столько на явные знания, сколько на «подводные». Например, как мы применили это в ситуации с Федей и стабилизацией релиза: «Федя, ты классно решаешь баги! Давай через полчаса соберём всю команду, и ты покажешь, как решишь новый». Главное, чтобы это не было заранее спланированное демо, в котором специально подобрали баг с минимумом проблем. При работе вслух можно вытащить много нового и интересного. Один раз мы получили скрипт, который позволял собирать и запускать сборку на устройстве за 30 секунд вместо 5 минут.
В базовом варианте этих двух способов мне хватает вытаскивать знания. Можно переходить к навыкам.
Навыки
Формула достаточно упрощённая, но для себя я её трактую именно в таком виде: навыки есть знания, умноженные на количество попыток применения этих знаний. Со знаниями мы разобрались — остаётся только увеличить количество попыток. Для этого идеально подходит стандартный метод — ротация по обязанностям.
Распределение навыков
1. Получение экспертизы на доработках
Самый простой способ обеспечить ротацию — разбить проект на этапы, и на каждом назначить новых людей на зону ответственности, которой занимались незаменимые сотрудники. Либо можно вообще передать доработку или сопровождение проекта другим сотрудникам, которые дополнят вам документацию и проработают архитектуру. Кстати, проработку техдолга проще всего отдать другим сотрудникам — они найдут новые баги и сделают всё по-другому.
2. Прототипирование
Если из команды приходят и говорят: «А почему вы начинаете просто так ротировать людей, которые делали что-то и, наверное, знают лучше», я практикую прототипирование. Незаменимый сотрудник делает что-то на коленке, что детально прорабатывается другой частью команды. Здесь есть одна проблема — вовремя остановить незаменимого сотрудника, чтобы прототип не стал MVP. Поможет немного микроменеджмента.
3. Ротация общих работ
Эта часть касается, как правило, тимлидов. Существует огромный пласт работ на плечах тимлида, к которому команда не имеет отношения. Что произойдёт в данном случае? Вы как руководитель станете незаменимым, а мы уже знаем, почему это не самый лучший вариант для вас. Подготовку демо, планирование, защиты и другую работу можно изредка поручать вашим сотрудникам. Это сработает не сразу и будет много проблем, придётся набраться терпения и раз за разом учить свою команду. Но поверьте, результат будет того стоить.
Культура расширенных обязанностей
Распределяйте задачи и ответственность практично. Например, вот как это может работать:
Упавшие автотесты
Если после упавших автотестов нужен разбор, а у вас вся команда говорит, что ждёт QA, то, вероятно, QA и станет потихонечку незаменимым. Но этим может заняться сотрудник, сделавший последнюю доброску или который сломал эти автотесты.
Проблемы с окружением
Кто занимается упавшей ночной сборкой? Почему бы это не сделать сотруднику, который первым пришёл на работу?
Уточнение требований продакта
Необязательно ждать аналитика, если это может сделать текущий сотрудник.
Задавая правильные вопросы на стендапах, прямыми указаниями и поощрениями инициативы можно создать культуру, когда каждый начинает отвечать за чуть большую область своих обязанностей. Так незаменимых сотрудников становится чуть меньше, можно отдохнуть.
Но есть нюанс, который касается перформеров. Например, моя жена читает раз в пять быстрее, чем я. Знаете ощущение, когда ты дочитываешь второй абзац, а она уже переворачивает страницу? Если мы хотим дочитать книжку и обсудить её, ей придётся ждать неделю. Но есть выход: «Дорогая, ты так прекрасно готовишь чай! Приготовь, пожалуйста, кружечку!». И у меня есть целых 5 минут для того, чтобы успеть дочитать страницу. Если этого недостаточно, тогда прошу борщ. В принципе, шансы уже совместимы. Этот способ я переношу на команды.
Вывод незаменимых сотрудников из операционной работы
Lite version
Работа вне операционной деятельности
Задача — немножечко отстранить перформеров от операционной деятельности. Дайте другой части команды догнать по знаниям, по навыкам самых лучших коллег. Нагрузите перформеров планированием, декомпозицией задач. Пусть, в конце концов, шляются по конференциям. Если вы придумаете красивое название для этой роли, например чемпион по конференциям или чемпион по планированию, они будут только счастливы.
Исследования
Если компания спрашивает, зачем, можете сказать, что у нас есть исследования. В современном C++ новый стандарт выходит каждые три года. Нужно понять, какие там на текущий момент баги и доказать, что нам на него действительно нужно переходить. Всё это может сделать ваш незаменимый перформер.
А если и этого мало, наймите стажёра.
Менторство
Знаете, сколько вопросов может задать один любопытный стажёр? Вы можете получить сильного миддла и немножко уставшего перформера.
Hardcore
Переходя к тяжёлой артиллерии:
Промоушен
Если у перформера есть потенциал для роста, вы можете собрать под него мини-команду. Если нет, необязательно промоутить в вертикаль. Например, недавно узнал, что одна из моих очень способных QA перешла в продакты. При таком решении вы оставляете экспертизу сотрудника внутри отдела, не увольняя его.
Перевод на другой проект / в другую команду
Человека не обязательно увольнять. Вы можете перевести его в другой отдел, оставив экспертизу хотя бы в рамках компании. Но это даёт шанс раскрыться всей остальной команде, поднять новые таланты. Возможно, ваш перформер является ограничивающим фактором для роста какого-то нового гения.
С чего начать изменения
Поговорить
Все новые методики учат тому, что нужно начать с разговоров с сотрудниками и объяснения наших целей.
Поставить цель
Вы не обязаны решать проблему сами. Вы можете её делегировать непосредственно вашему незаменимому сотруднику. Поставьте цель на следующие полгода, чтобы он передал свои знания, навыки и т. д.
План эвакуации
По-хорошему, каждый сотрудник должен иметь план B того, что будет происходить в отделе в случае его отсутствия. Единственная проблема с этим планом — надо периодически проводить пожарные учения, или он может устареть.
Итого, чек-лист:
оцифровываем знания;
настраиваем ротацию;
выводим перформеров из оперативки;
делегируем.
Что в итоге
В сложный период компании у меня из отдела ушло 40% сотрудников, но мы не сорвали ни одного релиза. Все проблемы решились внутренней ротацией. Любые задачи от руководства типа 100% покрытия автотестами или полного pipeline CI/CD решались мгновенно за счёт внутренней переброски ресурсов, потому что нанимать людей долго.
А ещё если вы решите сломать себе руку и полежать месяцок в больнице, производительность вашей команды не упадёт, качество останется прежним, и всё будет хорошо.
Скрытый текст
Ещё больше полезного для командных процессов можно будет узнать от моих коллег на следующей конференции Saint TeamLead — она пройдёт в Санкт-Петербурге в июне 2026 года. Присоединяйтесь, чтобы пообщаться не только в комментариях, но и на живом нетворкинге и мастер-классах.
