В ИТ любят героев. Человека, который ночью поднял прод, за выходные переписал критичный модуль, взял на себя чужие задачи и спас релиз, обычно благодарят. Иногда вполне заслуженно.
Проблема начинается там, где героизм становится не исключением, а обычным способом работы.
Иллюзия силы
Героический режим создаёт иллюзию силы: мы справились, значит всё в порядке. Но за кулисами копится долг — технический, процессный, эмоциональный. Если систему регулярно приходится спасать, значит она устроена так, что без спасателей не работает.
Как подвиг поддерживает проблему
Лидер, который постоянно закрывает дыры вручную, может не замечать, что сам поддерживает эту культуру. Каждый подвиг снижает срочность системных изменений. Зачем чинить процесс, если всегда найдётся человек, который вытянет? Зачем пересматривать планирование, если можно ещё раз попросить команду «собраться»?
Ответственность, которая выглядит скучнее
Ответственность без героизма выглядит менее эффектно. Это честное планирование, своевременная эскалация, отказ от лишнего объёма, инвестиции в тесты и документацию, нормальные дежурства, разговоры о рисках до того, как они стали пожаром.
Это скучнее. Зато здоровее.
После кризиса
Важно отличать редкий кризис от постоянной модели. Иногда действительно нужно собраться и помочь. Но после кризиса зрелая команда не просто выдыхает и идёт дальше. Она спрашивает: почему это случилось, что сделало нас уязвимыми и как снизить вероятность повторения?
Ценность не только в спасении
Героизм опасен ещё и для самооценки. Человек привыкает быть ценным только в режиме спасения. Спокойная работа начинает казаться недостаточно значимой. Хотя настоящая зрелость часто проявляется именно в том, что пожаров становится меньше.
Хорошая команда — не та, где всегда есть герой. Хорошая команда — та, где героизм не нужен как регулярный механизм выживания.
