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