Почему система начинает жить за счёт героизма людей

После прошлой темы всё чаще начал ловить себя на одной мысли.

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

Причём самое интересное —
для большинства это уже давно не воспринимается как проблема.

Наоборот.

Именно таких людей
часто считают
самыми сильными сотрудниками внутри системы.

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

И действительно.
На определённом этапе именно такие люди часто помогают системе не развалиться.

Проблемы решаются.
Процессы двигаются.
Критические сбои не происходят.

И постепенно вокруг них
сама организация начинает выстраивать часть своей работы.

Потому что так:
проще,
быстрее,
привычнее
и комфортнее для окружающей среды внутри системы.

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

👉 Какие ограничения
создаёт сама модель постоянной ручной компенсации?

Потому что одно дело —
когда процессы работают устойчиво.

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

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

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

Причём чаще всего —
из лучших побуждений.

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

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

И это действительно помогает.

Более того,
для окружающих
это начинает выглядеть
как высокая эффективность.

Человек постоянно занят.
Всегда включён в процессы.
Быстро реагирует.
Решает проблемы “в моменте”.
Удерживает огромное количество вопросов одновременно.

И постепенно система начинает к этому привыкать.

Причём часто —
даже не замечая этого.

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

И тогда внимание начинает смещаться:
не на улучшение архитектуры процессов,
а на поиск тех,
кто снова сможет “вытащить ситуацию”.

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

Потому что это удобно.

Все привыкают,
что этот человек:
📍 справится
📍 ускорит
📍 договорится
📍 компенсирует
📍 и удержит систему от сбоя.

И постепенно вокруг него
начинает выстраиваться уже часть устойчивости всей организации.

Иногда это очень напоминает спорт.

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

И наоборот.

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

Но при перегрузке,
смене темпа
или потере ключевого игрока
её устойчивость начинает резко снижаться.

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

Но у такой модели
есть ещё одно ограничение.

Как правило,
в этот момент
организация идёт по самому понятному для себя пути.

Она не пытается глубоко разобраться:

👉 почему без этого человека
всё начало работать хуже.

Она начинает искать:

👉 кем его заменить.

Потому что это самый быстрый,
понятный
и привычный способ
вернуть системе прежнюю устойчивость,
не перестраивая сами процессы.

И здесь появляется ещё одна проблема.

Мы часто думаем:

“нужно найти такого же сильного человека”.

Хотя одинаковых людей не существует.

Потому что герой —
это не должность.

Это:
📍 уникальная комбинация опыта
📍 характера
📍 памяти
📍 скорости реакции
📍 связей
📍 авторитета
📍 способности жить в перегрузе
📍 готовности брать ответственность
📍 и умения удерживать хаос внутри своей головы.

Другой человек
может быть профессиональным.
Может быть сильным.
Может быть опытным.

Но это уже будет другая личность.

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

И далеко не факт,
что он сможет удерживать систему
через те же самые отклонения.

Причём здесь есть ещё одна важная вещь,
о которой редко говорят.

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

Потому что герой,
как правило,
не только помогает системе.

Он ещё и:
📍 обходит ограничения
📍 ускоряет согласования
📍 создаёт исключения
📍 решает вопросы “вне системы”
📍 и иногда маскирует нарушение архитектуры
под правильное решение.

Причём чаще всего —
из лучших побуждений.

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

Другие люди начинают видеть:

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

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

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

Но потом эту модель поведения
начинают копировать другие.

Уже:
без опыта,
без понимания всей системы
и без способности удерживать последствия своих решений.

И тогда архитектура начинает размываться ещё быстрее.

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

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

И постепенно:
📍 перегруз
📍 текучка
📍 постоянное “тушение пожаров”
📍 зависимость от конкретных людей
📍 нестабильность процессов
📍 и накопленная усталость системы
начинают становиться
не исключением,
а привычным стилем работы.

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

Героизм —
это ручная компенсация сложности.

А возможности человека ограничены.

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

На определённом уровне
часть процессов ещё можно удерживать:
📍 опытом
📍 памятью
📍 личными договорённостями
📍 скоростью реакции
📍 и ручной координацией.

Но чем больше становится:
— процессов
— людей
— информации
— взаимосвязей
— скорости изменений
— и количества отклонений,

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

И тогда сама система
начинает наследовать ограничения конкретных людей.

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

И здесь невольно возникает простой вопрос.

Какая лампочка прослужит дольше:
та,
которую включают только ночью,
или та,
которая горит круглые сутки?

Наверное,
примерно так же
работает и постоянный героизм внутри системы.

И как мне кажется,
здесь появляется очень важная мысль.

Герои нужны любой организации.

Потому что идеальных процессов не существует.

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

Это нормально.

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

Потому что героизм должен помогать:
📍 переживать кризис
📍 исправлять отклонения
📍 удерживать систему в сложный момент.

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

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