Как компания делает сотрудника незаменимыми почему это выглядит как токсичность

9 августа 2026 · 9 минут

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

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

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

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

Незаменимость не возникает сама

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

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

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

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

1. Сложная система и слабые процессы
2. Один человек становится обязательной точкой
3. Растут его нагрузка и контроль
4. Команда теряет автономность
5. Вокруг роли может расти напряжение
6. Организация рискует увидеть только «токсичного сотрудника» и не исследовать устройство работы

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

Часть монополии хранится не в коде

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

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

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

Кейс 1. Деплой одного человека

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

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

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

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

Сначала — воспроизводимый релиз

Мы начали с воспроизводимого деплоя. Автоматизировали его через CI/CD, сделали выпуск без простоя и откат примерно за три минуты. Запускать деплой смогла вся команда разработчиков, вплоть до владельца продукта.

Автоматизация убрала исключительное право одного человека переводить работу команды в production. Компания получила способ проверять изменения независимо от его доступности.

1. Стабилизировали инфраструктуру и системно разбирали причины падений.
2. Провели ревизию бизнес-логики и модели данных — и отказались от полного переписывания.
3. Выделили новый слой API и переносили запросы в новую серверную часть поэтапно, с сохранением обратной совместимости.
4. После достаточной миграции перестали добавлять новые функции в старую часть системы.

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

Результат: команда продолжила работу без эксперта

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

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

Кейс 2. Узкое место команды

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

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

В этом проекте сильный эксперт был не только носителем знаний: через него проходили технические решения и значительная часть работы команды. Операционная зависимость усиливала его влияние и трение вокруг роли.

Разделить систему так, чтобы разделить ответственность

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

1. Вынесли часть запросов на чтение данных в новую серверную часть и ускорили их обработку.
2. Переносили сценарии изменения данных от простых к сложным, добавляя мониторинг и автоматизацию.
3. Переносили знания в документацию и процессы, чтобы вход в проект не шёл только через одного эксперта.
4. Распределяли владение задачами и готовили нескольких людей, способных заменить эксперта.

Новые технические границы позволили передавать части работы разным людям без передачи им всего накопленного контекста сразу.

Результат: зависимость ушла не везде

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

Граница результата здесь важна. На уровне компании зависимость от ключевого эксперта исчезла, но сохранилась внутри мобильного приложения, которое он лично развивал. Руководство осознанно оставило эту локальную монополию.

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

Один механизм в разных проектах

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

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

1. Сделать эксплуатацию и восстановление воспроизводимыми.
2. Создать технические границы, по которым систему можно передавать частями.
3. Перенести знания из личных объяснений в документацию, мониторинг и автоматизацию.
4. Распределить доступы, решения и владение — и проверить результат реальной работой без участия прежнего эксперта.

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

Диагностика зависимости

Руководителю не нужно начинать с психологической оценки. Сначала достаточно ответить на несколько операционных вопросов:

1. Кто выпустит релиз без личного разрешения эксперта?
2. Кто восстановит систему, если он будет недоступен две недели?
3. Какие решения невозможно проверить по коду, документации и истории изменений?
4. Может ли кто-то кроме него отличить обязательное бизнес-правило от случайного поведения legacy-кода?
5. Что остановится в первый день после его ухода?

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

Что не снимает зависимость

Сколько это стоит и когда риск можно принять

Снятие зависимости требует времени. В первом кейсе команда потратила его на воспроизводимый релиз, стабилизацию инфраструктуры и поэтапную миграцию — эти же усилия бизнес мог направить на новую функциональность. На коротком горизонте концентрация экспертизы поэтому может казаться дешевле.

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

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

Вместо заключения

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

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

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

Автор: Данил Письменный · Дата: 9 августа 2026