Пятница, конец спринта. Команда сдала всё в срок. Клиент доволен. Тишина в радиоэфире. Я смотрю на экран и понимаю: работу затащили, как и всегда, но какой ценой?
Команда не выгорела, а я — да .
Выгорел, следя, чтоб не выгорела команда — иронично.

Два голоса, которые живут в голове у каждого

Ещё когда я был разработчиком, в голове жили два персонажа. Звучит как начало разговора с психотерапевтом, но я объясню:

Первый — назову его Прагматик — говорил примерно следующее: делай минимум, чтоб не уволили. Клиент принял, задача закрыта, все живы — отлично. Иди домой.
Прям китайский мудрец…

Второй — Перфекционист. Этот не унимался: а вот тут можно лучше. А вот это решение — костыль. А вот эта функция через полгода будет болеть. Давай переделаем. Мы же за качество, нечего тут клепать мусор.

Прагматик экономил время. Перфекционист экономил репутацию. В теории между ними должен быть баланс. Но на деле они просто по очереди портили какую-то часть моей жизни.

Говорят, что этим страдают многие в IT, что‑то вроде профессиональной деформации. Время шло, я учился ловить баланс и двигался по карьерной лестнице, пока не стал ушёл в менеджмент. Только вот проблема никуда не делась — она просто нашла новую нишу.

Переход в новую деятельность

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

Но, как говорится, добро пожаловать.

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

Онбординг нового человека: нужно проследить, чтоб быстро адаптировался.
Ретроспектива: все всё поняли? Все всё уяснили?
Задачи: точно ли очевидны? точно ли все всё понимают?
O2O: воздух потрясём или решение найдём?

Хороший менеджер вроде должен об этом думать. Проблема в том, когда остановиться. Где граница того, в какой момент контроль можно ослабить и ничего не рассыпется?

Выгорание в обучении

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

А тут — новая сфера, где надо проявить себя и задержаться, потому раз уж взялся делать что-то новое, будь добр доделать до конца. Не умеешь — научись, не понимаешь — разберись.

Перфекционизм жрёт энергию на оценку работы. Снова и снова. И эта оценка на этапе, когда ты учишься чему-то новому, почти всегда «можно было и лучше».

Про команды

Я следил за тем, чтобы люди не выгорали. Это правда. Смотрел на загрузку, старался не перегружать, разговаривал — спрашивал как человек, а не как менеджер на 1:1 по чек‑листу. Фидбек от команды был достойным.

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

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

А что, беда только в твоей голове?

Со временем, анализируя каждый цикл работы, результатов, ощущений, я начал потихоньку понимать: дело не только в моём перфекционизме. Пара мелочей в примеры:

Споры с заказчиком про часы. Часть моей работы — следить, чтобы команда не перерабатывала. Звучит просто. На практике это означало регулярные разговоры с заказчиком в духе «нет, мы не можем добавить это в спринт, потому что люди уже на пределе». Заказчик давил, я отбивался, команда об этом часто даже не знала. Каждый такой разговор — отдельный расход энергии, который в табеле не учитывается.
Результат — команду откусал, сам утомился.

Весёлые метрики сверху. В какой-то момент начальство решило, что хочет видеть моё «участие» в работе. Метрикой выбрали количество код-ревью, которые я провёл, причём не в своей команде, а вообще по отделам.

Знаю, у кого-то так принято, но, по-моему, это странно: у меня есть сильные разработчики, у которых ревью получается лучше моего, и моя задача — не перепроверять их, а убирать блокеры.

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

Чайка-менеджмент по расписанию. Иногда сверху прилетало негласное ожидание: руководитель должен быть заметен в процессах.
Влетать, смотреть, комментировать.
Даже однажды рассказали мне про какого-то руководителя департамента, который работает по 14 часов в день, успевает следить за маркетингом, аналитиками, разработчиками, читает каждую доку, сам строит архитектуру, сам пишет тексты, и ещё в свободное от работы время в качестве девопа инфру обновляет и пэт-проекты делает.
Вот, мол, повод для гордости!

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

В общем, объединяем всё:

• Попытку защитить команду

• Попытку научиться делать хорошо новую работу

• Попытку пробивать непробиваемое начальство

И всегда плата — время и ресурс.

Команда уходила домой вовремя. Я оставался. Иногда за полночь.

Что я пробовал и что не работало

Я не буду делать вид, что нашёл решение. Его нет — или я пока не нашёл.

Но кое‑что про механику понял.

Списки задач не помогают, если проблема не в задачах. Я несколько раз пытался «оптимизировать» своё время: расписывал по блокам, расставлял приоритеты, убирал лишнее. Становилось чище, но не легче. Дело было не в количестве задач, а в том, что каждую я прокручивал дольше, чем нужно.

«Просто отпусти, дай волю прагматику» — худший совет. Слышал его в разных формулировках. Делегируй. Доверяй команде. Не лезь в детали. Всё это правильно и примерно так же полезно, как совет «просто не грусти». Хотя направление и верное, но как к этому прийти?

Помогло другое.
Нет, тут не история про то, как я нашёл решение.
Просто… Прошло время….
Есть такое выражение: если куда-то идти, то ты куда-то придёшь.

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

Вместо вывода

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

Есть наблюдение: самые выгоревшие менеджеры, которых я видел — это те, кто не мог выключить вовремя оценку. Своей работы, чужой работы, процессов, решений.
А ещё те, кто слишком много держит в голове и не выносит в более устойчивые носители.

Смешно, что именно такие люди чаще всего следят за тем, чтобы команда отдыхала.

В общем, я продолжаю учиться, бороться с внутренними демонами, не выгорать. Буду рад, если вы проходили то же, и дадите добрый совет.