В воскресенье в 20:00 дизайнер правит макет, владелец продукта допиливает пользовательский путь, а менеджер заходит в Фигму, чтобы принять работу и раздать новые задачи. Эта сцена, как пишет Habr / Менеджмент, стала отправной точкой для разговора не про личную неэффективность, а про системную поломку: средний менеджмент в IT работает так, будто увольнение сотрудника, релиз без тестов и выбор цвета кнопки лежат в одной очереди. Для русскоязычной IT-аудитории это болезненно узнаваемая картина: если у вас «всё срочно», то дело уже не в тайм-менеджменте.
Автор текста Александр Мартынов формулирует проблему жестко: обычная управленческая практика в компаниях нарушает три ограничения, которые не обойдет даже гипотетический сверхинтеллект. Первая идея проста: нельзя реагировать на каждое отклонение. В пример приводится автопилот Tesla, который не подруливает каждую миллисекунду, а держит машину в допустимом коридоре и вмешивается, только когда траектория выходит за границы. В управлении командами всё наоборот: метрика просела, клиент написал, кто-то эскалировал в чат, руководитель сверху переспросил статус, дизайнер задержал правку на день, разработка не уложилась в оценку, маркетинг принес новый дедлайн. Если на каждое такое событие отвечать как на аварию, система начинает трясти не хуже автомобиля, который пытаются выровнять по каждому камешку на асфальте.
Вторая мысль бьет по самому уязвимому месту российского корпоративного менеджмента: у нас часто не разделяют обратимые и необратимые решения. В инженерной логике разница очевидна. Удалить файл, откатить коммит или вернуть ветку еще можно; потерять production-данные, сломать основной репозиторий или лишиться критичного ключа доступа — уже другой класс событий. Формально это всё тоже действия в интерфейсе или команды в консоли, но цена ошибки у них несопоставима. Автор переносит эту логику на управление людьми и продуктом: найм, увольнение, смена стека, отказ от направления, перенос ответственности между командами часто проходят через ту же процедуру и тот же темп, что и согласование названия релиза или мелкой правки в интерфейсе. Отсюда и главный образ текста: для среднего менеджмента в IT rm file и rm -rf / слишком часто выглядят как задачи из одного списка.
Третье ограничение касается правил. Если организация управляется не правилами, а ручными исключениями, стоимость координации быстро растет, а сами правила превращаются в декорацию. Пример из статьи предельно приземленный: команда договорилась не выпускать фичи без тестов, но в середине квартала приходит приказ «надо к понедельнику, сейчас не до тестов». Кажется, что это единичный компромисс. На практике команда получает другой сигнал: правило существует, пока на него не надавили. После этого исключение становится рабочим инструментом для всех соседних функций — от внедрения до маркетинга. Через месяц тесты пишутся только там, где совсем нет дедлайна, то есть почти нигде. Для разработчиков это знакомая ловушка: неформальная гибкость сначала ускоряет релиз, а потом съедает качество, прогнозируемость и доверие внутри команды.
На этом месте текст особенно попадает в нерв рынка. Последние годы российские IT-команды живут в режиме постоянной турбулентности: импортозамещение, переделка продуктовых воронок, смена подрядчиков, кадровый дефицит, рост требований к скорости доставки. На таком фоне средний менеджмент в IT часто пытались чинить через личную дисциплину: лучше планировать, жестче вести бэклог, внедрять новые ритуалы, читать книги про продуктивность, учиться «распожаризации». Мартынов описывает собственный неудачный опыт именно с этой стороны. Он пытался обучать коллектив более рациональной работе, но дальше вводного занятия дело не пошло: у людей не было ни времени, ни сил, ни базового ресурса. Общей деталью оказался плохой сон. Состояние удалось немного улучшить, стресс снизился, работоспособность выросла, но дополнительные силы ушли не на перестройку системы, а на то, чтобы дальше бегать вокруг тех же пожаров.
Это важное наблюдение для продактов, тимлидов и IT-директоров. Если команда хронически недосыпает, а менеджеры все время реагируют на входящий поток, можно бесконечно полировать личные практики, но сама конструкция останется прежней. Автор формулирует это почти без надежды на магию: «распожаризация невозможна, пока работают поджигатели». В переводе на язык бизнеса это значит, что компании часто одновременно требуют от людей нарушать все три ограничения. Нужно отвечать на каждое отклонение, одинаково быстро принимать решения разного класса риска и каждый раз заново разруливать то, что должно было быть закреплено правилом. Для собственника или директора такая схема может выглядеть как высокая вовлеченность. Для команды она оборачивается тем, что любой компетентный менеджер постепенно превращается в дорогостоящий маршрутизатор чужой тревоги.
Практическая часть статьи намеренно приземлена. Вместо очередного манифеста про осознанность автор предлагает хотя бы минимально развести потоки решений. Во-первых, описать для себя три «скорости» реакции и зафиксировать, на какие типы вопросов не отвечать в первые сутки. Не из героизма, а как политику защиты от навязанной срочности. Во-вторых, завести отдельную очередь для необратимых решений, которые нельзя пихать между созвонами и правками в интерфейсе. Сам факт отдельного окна уже меняет качество обсуждения. В-третьих, укреплять правила так, чтобы они не отменялись первым же давлением сверху. Для бизнеса это неприятный вывод: гибкость, которой гордятся многие команды, нередко оказывается обычной отменяемостью любых договоренностей.
В сухом остатке статья на Habr спорит не с людьми, а с устройством работы. Она не обещает, что один фреймворк, один курс или один сильный менеджер вытащит систему, где все решения свалены в кучу и каждое исключение обучает организацию нарушать собственные правила. Для отрасли это неприятный, но полезный сигнал: пока средний менеджмент в IT меряют готовностью тушить любой пожар в любую минуту, компании будут терять не только энергию людей, но и качество решений. Главный вопрос теперь не в том, как выжать из менеджера еще немного эффективности, а в том, готов ли бизнес наконец признать, что не всякая срочность заслуживает немедленной реакции.