Управленческий use case: как превратить bus factor = 1 в комьюнити экспертов
Есть архитектор, который сделал внутреннюю платформу для быстрой сборки интеграций.
По сути — свой low-code инструмент, чем-то похожий на n8n.
Платформа рабочая, живёт в production и позволяет довольно быстро собирать новые сценарии.
Но со временем появилась системная проблема: команды всё чаще начали упираться в одного человека.
Новая интеграция — к нему. Изменение сценария — к нему. Сложный кейс — снова к нему.
И даже если конкретно он работает очень быстро, на уровне всей системы это постепенно превращается в bottleneck.
Можно было просто сказать: «Надо срочно передать знания команде».
Но такой подход обычно плохо работает. Особенно когда человек сам построил систему и объективно знает её лучше всех.
Поэтому решили идти постепенно.
Сначала берём одного сильного инженера и одну реальную задачу. Архитектор не делает её сам, а только консультирует и ревьюит.
Если получилось — берём второго.
Потом первый инженер уже помогает второму.
То есть знание начинает распространяться не по схеме:
архитектор → все
а по схеме:
архитектор → первый эксперт → второй эксперт → остальные
Через несколько таких итераций у нас появляется уже не один носитель знания, а небольшое комьюнити экспертов по платформе.
Дальше этих людей можно посадить в разные продуктовые команды.
И тогда модель меняется принципиально.
Раньше: команда → архитектор → очередь → решение
После: команда → свой эксперт → решение
А архитектор остаётся там, где он действительно нужен: архитектурные изменения, сложные кейсы, развитие самой платформы.
Мне нравится этот подход тем, что мы не пытаемся одномоментно «размазать знания по всей организации».
Мы распространяем их контролируемо: 1 человек → 2 → 4 → несколько команд.
По сути, строим внутреннюю сеть компетенции.
И здесь важный управленческий вывод.
Иногда проблема сильного эксперта не в том, что он слишком много на себя забрал. И не в том, что он «вредный».
Проблема в том, что организация слишком долго строила процесс вокруг одного человека.
Поэтому задача руководителя — не убрать этого человека из центра.
А сделать так, чтобы его знания начали масштабироваться быстрее, чем растёт очередь к нему.
