The post has been translated automatically. Original language: Russian
The "Irreplaceable Employee" Syndrome: Why is your team walking on the edge of a precipice
The IT community likes to praise engineers who "know everything" and can fix any bug at 3 a.m. But let's look at it from the point of view of system engineering. An indispensable person in a team is a huge architectural vulnerability.
In management, there is a concept of Bus Factor — the number of project participants who must be hit by a bus in order for the project to stop completely. If your entire legacy system is based on one Berik, your Bus Factor is one. This is a critical level of risk.
How to understand that you are trapped in a "mental monopoly":
- The bottleneck on Code Review: Pull requests have been hanging for weeks, because "only Konysbek can approve this part."
- Guerrilla development: The code is written quickly, but there is no documentation, because "everything is clear to the author, but the rest is not needed yet."
- Fear of vacation: Talgat, a key engineer, cannot fully go on vacation — his phone bursts with Slack tags at the slightest glitch.
, A useful checklist: how to reduce risks right now
If you are a team leader or the very "Berik" himself, start implementing these three practices.:
- Documentation as code (Docs-like-code): Get the team to write architectural solutions (ADR — Architecture Decision Records) directly in the repository. No ADR feature is not included in the product.
- Forced task rotation: Once a quarter, transfer support for a complex module to a developer from a neighboring sub-team. Let him fill in the bumps on the debug, while the expert is nearby and can tell you.
- "Days without the irreplaceable": Arrange an experiment — send a key engineer for a week to an internal hackathon or training with a complete ban on touching the main code. The team will immediately see where its "blind spots" are in the processes.
The destruction of the mental monopoly frees the most "irreplaceable" from burnout and eternal duty, and gives the rest of the team a powerful boost in growth.
Синдром «Незаменимого сотрудника»: почему ваша команда ходит по краю пропасти
В ИТ-комьюнити любят хвалить инженеров, которые «знают всё» и могут починить любой баг в 3 часа ночи. Но давайте посмотрим на это с точки зрения системного инжиниринга. Незаменимый человек в команде — это огромная архитектурная уязвимость.
В менеджменте есть понятие Bus Factor (фактор автобуса) — количество участников проекта, которых должен сбить автобус, чтобы проект полностью остановился. Если у вас вся легаси-система держится на одном Берике, ваш Bus Factor равен единице. Это критический уровень риска.
Как понять, что вы попали в ловушку «ментальной монополии»:
- Узкое горлышко на Code Review: Пулл-реквесты висят неделями, потому что «аппрувнуть эту часть может только Конысбек».
- Партизанская разработка: Код пишется быстро, но документации нет, потому что «автору и так всё понятно, а остальным пока не надо».
- Страх отпуска: Ключевой инженер Талгат не может полноценно уйти в отпуск — его телефон разрывается от тегов в Slack при малейшем сбое.
🛠️ Полезный чек-лист: как снизить риски прямо сейчас
Если вы тимлид или сам тот самый «Берик», начните внедрять эти три практики:
- Документация как код (Docs-like-code): Заставьте команду писать архитектурные решения (ADR — Architecture Decision Records) прямо в репозитории. Нет ADR — фича не идет в прод.
- Принудительная ротация задач: Раз в квартал передавайте поддержку сложного модуля разработчику из соседней подкоманды. Пусть набьет шишки на дебаге, пока эксперт рядом и может подсказать.
- «Дни без незаменимых»: Устройте эксперимент — отправьте ключевого инженера на неделю на внутренний хакатон или обучение с полным запретом трогать основной код. Команда сразу увидит, где у нее «слепые зоны» в процессах.
Уничтожение ментальной монополии освобождает самого «незаменимого» от выгорания и вечного дежурства, а остальной команде дает мощный буст в росте.
Share
