Команда, работающая на пределе, может показать красивую скорость на коротком отрезке, но потом бизнес получает выгорание команды, ошибки и увольнения сильных специалистов. Именно к такому выводу пришел руководитель IT-направлений, который за 15 лет провел более 300 интервью, управлял штатом в 100 человек и вел в 2024 году программу внедрения нового биллинга в федеральной телеком-компании, сообщает Habr / Карьера.
Главный тезис автора звучит неприятно для любителей «поджать сроки любой ценой»: загрузка на 100% в обычном режиме не повышает устойчивость команды, а, наоборот, лишает ее запаса прочности. Пока все спокойно, люди еще держат темп. Но как только прилетает внеплановая задача, инцидент, сдвиг сроков или новая волна требований, система начинает сыпаться. Сначала действительно может расти скорость, затем увеличивается число ошибок, начинаются конфликты, а после этого уходят те, кого рынок забирает быстрее всего, то есть сильные сотрудники.
Автор опирается не на теорию из презентации для совета директоров, а на несколько собственных управленческих циклов. Он вспоминает 2015 год, когда руководил штатом из 100 человек, и 2024-й, когда отвечал за программу внедрения нового биллинга в федеральной телеком-компании. В обоих случаях он видел одну и ту же управленческую схему: производительность пытались поднимать через контроль, переработки и постоянное давление. На старте это давало иллюзию результата, потому что команда ускорялась. Но дальше бизнес, по его словам, терял больше денег, чем успевал заработать: проседала эффективность, росли издержки на найм, а замена сильного специалиста занимала слишком много времени. На фоне дефицита опытных кадров в IT такой подход он прямо называет финансовым самоубийством для компании.
Отсюда и более широкий вывод, важный не только для тимлидов, но и для продактов, CTO и HR: эффективность команды нельзя всерьез измерять количеством отработанных часов. Автор пишет, что перестал пользоваться такой логикой именно потому, что часы неплохо считают присутствие, но плохо объясняют результат и почти ничего не говорят о будущих рисках. Его формула жестче и прагматичнее: мотивация сотрудников нужна не как «пряник», а как инструмент управления рисками и капитализацией человеческого ресурса. Если перевести это с управленческого на обычный русский, смысл простой: удержать адекватную, работоспособную команду часто выгоднее, чем еще квартал выжимать из нее сверхусилие.
Вместо режима постоянного форсажа автор предлагает четыре рабочих принципа. Первый — синхронизация личных целей сотрудников с целями компании. На входе он спрашивает кандидатов не только про стек и опыт, но и про «мечту»: кому-то важна асинхронная работа и жизнь за городом, кому-то нужен понятный трек в лидерскую роль. Логика здесь прозрачная: если работа помогает человеку двигаться к его собственной цели, лояльность и вовлеченность растут заметно сильнее, чем от очередной денежной надбавки. Второй принцип — инженерная культура и T-shape-подход. Менеджер, по этой модели, не обязан писать код по ночам, но должен понимать, как устроен интернет, зачем нужна виртуализация и почему инфраструктурные ограничения вообще существуют. Автор даже приводит пример с походами сотрудников в дата-центры: такая практика сокращает коммуникационные разрывы между бизнесом и разработкой лучше, чем многие многочасовые синки.
Третий принцип — управление через доверие, а не через микроконтроль. Регулярные 1-to-1 он использует как способ измерять состояние команды до того, как недовольство превратится в поток увольнений. В разговорах фиксируются ожидания в SMART-формате, а неформальные активности вроде квизов или BBQ работают не как «обязательная корпоративная радость», а как индикатор состояния социальной жизни внутри команды. Это важный нюанс: в перегретом IT-рынке сотрудники редко уходят внезапно. Обычно до этого есть длинная стадия усталости, раздражения и ощущения, что из человека сделали фабрику задач. Если руководитель видит только статус по Jira, эта стадия проходит мимо него.
Четвертый принцип — тот самый буфер, который многим кажется роскошью, пока не приходится тушить пожар. Автор держит нормальную загрузку на уровне 80%, а оставшиеся 20% рассматривает как резерв под критические задачи. Он ссылается на подход «бережливого управления людьми»: если команда в мирное время и так работает на 100%, то при первой же перегрузке ей просто некуда ускоряться. Для бизнеса это особенно актуально на длинных проектах, где цена ошибки выше, чем на коротком спринте. В заметке есть и конкретный кейс: в 2021 году на проекте создания комплекса CRM + ERP для производственной компании команда несколько кварталов подряд жила почти при полной загрузке. Сначала velocity росла, затем увеличилось число ошибок, обострились конфликты и уволился главный разработчик. После пересмотра планирования и введения буфера по загрузке и WIP ситуация стабилизировалась, а производительность на длинной дистанции оказалась выше.
Для русскоязычной IT-аудитории эта история важна еще и потому, что она бьет по старому управленческому мифу: будто выгорание команды — это мягкая гуманитарная тема, а не вопрос экономики. В действительности именно экономика здесь и становится главным аргументом. Финансовая мотивация, как пишет автор, работает недолго. Контроль дает короткий всплеск. Переработки удобны только на слайде, где квартальный график еще не успел встретиться с увольнением ключевого разработчика. А вот текучесть не выше 5%, которую автор называет для своих команд, уже выглядит как показатель, на который бизнесу стоит смотреть не меньше, чем на velocity и процент закрытых задач.
На практике это ставит перед компаниями неприятный, но полезный вопрос: готовы ли они и дальше покупать ощущение управляемости ценой выгорания команды, или все-таки признают, что резерв мощности, инженерная культура и нормальная человеческая мотивация обходятся дешевле, чем очередной цикл найма после массовой усталости и точечных уходов ключевых людей.