Пока я оберегал команду от выгорания, перегорел сам
Пятница, конец спринта. Все задачи закрыты, демо прошло гладко, заказчик доволен и разошёлся по своим делам. В чатах тишина, ребята постепенно расходятся. На доске - зелёные галочки, в трекере всё красиво. На бумаге - идеальный спринт.
Я сижу перед монитором и понимаю: да, команду мы вывезли. Опять. Все целы, никто не сгорел, никто не ночевал в офисе и не сидел до часа ночи в Zoom. Но чем дольше я смотрю на экран, тем отчётливее чувствую: пока я держал их в ресурсе, выгорел сам.
Иронично. Я выстраивал процессы так, чтобы люди не уставали и не ломались на длинной дистанции. Следил за нагрузкой, поддерживал, закрывал собой сложные разговоры с заказчиком, отбивал лишние задачи. И постепенно оказался в роли того самого буфера, который принимает на себя весь удар, пока остальные работают комфортно.
Два голоса в голове, с которыми живут многие
Ещё когда я был разработчиком, в голове поселились два постоянных персонажа. Звучит как заготовка для психотерапии, но это так.
Первый - назовём его Прагматик. Его мантра была проста:
"Сделай ровно столько, сколько нужно, чтобы задача была закрыта и тебя не уволили. Клиент доволен, тесты зелёные, дедлайны соблюдены - выключай ноутбук и живи дальше".
Он призывал не драматизировать, не лезть туда, где "и так нормально работает", не перерабатывать и не умирать ради лишней звёздочки в Jira.
Второй - Перфекционист. Его голос звучал иначе:
"Здесь можно сделать лучше. Тут архитектура на костылях. Эту фичу через полгода будут ненавидеть. Давай перепишем сейчас, пока не поздно. Мы же за качество, не будем плодить мусор".
Прагматик экономил время и нервы.
Перфекционист защищал репутацию, кодовую базу и моё внутреннее чувство профессионализма.
На бумаге между ними должен был возникать здоровый баланс. На практике они просто по очереди портили мне жизнь: либо я горел на переработках, доводя всё до блеска, либо чувствовал вину за то, что "пропустил возможность сделать идеальнее".
У многих в IT это не баг, а почти стандартная конфигурация: профессиональная деформация плюс среда, где "качество" и "быстро" всегда дерутся между собой.
Со временем я кое-как научился держать этих двух в узде, рос, брал больше ответственности и постепенно ушёл в менеджмент. Но проблема не исчезла - она просто сменила форму.
Переход в менеджмент: меньше кода, больше выгорания
Когда я решил уйти из программирования в управление, картинка в голове выглядела привлекательно:
теперь я буду меньше копаться в мелких задачах и больше думать стратегически. Больше смысла, меньше рутины. Казалось, что это естественный шаг вверх.
На деле вышло иначе.
Перфекционист никуда не делся. Он просто сменил поле боя. Вместо "эта функция написана неидеально" началось:
- онбординг нового сотрудника - "надо, чтобы за неделю человек чувствовал себя уверенно";
- ретроспектива - "точно ли все сказали, что думают, и поняли, что решили?";
- таски в спринте - "действительно ли всем всё понятно, или кто-то стесняется спросить?";
- индивидуальные встречи - "мы просто проговорили воздух или пришли к конкретным решениям?".
Формально так и должен мыслить хороший руководитель: думать о процессе, о людях, о качестве решений, об эффективных встречах и честной обратной связи. Вопрос в другом - где поставить предел? В какой момент можно перестать контролировать и допустить, что что-то будет сделано не так, как ты бы сам?
Разработчиком быть было проще: знакомые инструменты, понятные процессы, устоявшиеся тайминги, предсказуемый результат. Там я понимал, что именно контролирую.
Менеджмент - новая территория. Хочется доказать, что ты не зря сюда пришёл. Раз уж взялся - сделай "как надо". Не умеешь - срочно научись. Не понимаешь - разберись до конца.
И вот уже перфекционизм начинает сжирать энергию не на написание кода, а на бесконечную оценку своей управленческой работы. Каждый разговор, каждое решение, каждый провал или конфликт становится поводом для внутреннего приговора: "можно было лучше, умнее, мягче, жёстче, быстрее".
Когда ты учишься новому, этот внутренний вердикт почти всегда один и тот же: "не дотянул". И в какой-то момент это становится фоном, из которого очень трудно выйти.
Как я оберегал команду - и загнал себя
Я правда следил за тем, чтобы люди не выгорали. Это не красивая фраза, а вполне конкретные действия:
- смотрел на загрузку и сознательно не забивал спринты под завязку;
- не толкал людей на переработки "ради важного релиза";
- регулярно общался один на один не по чек-листу, а как с людьми - с вопросами "как ты справляешься? что тебя сейчас выматывает? чего не хватает?".
Обратная связь от команды была хорошей:
атмосфера адекватная, пожарных задач - минимум, переработки - скорее исключение, чем правило. Люди были в ресурсе.
Параллельно я тренировал в себе ещё один навык: не влезать в каждую техническую мелочь. Я видел места, где решение сделано грубовато, документация написана наспех, архитектура могла бы быть элегантнее. И каждый раз нужно было выбирать: потратить ресурс команды (и свой) на доведение до идеала - или принять "достаточно хорошо" и двигаться дальше.
У менеджеров с техническим прошлым есть особое искушение:
"Раз я знаю, как правильно, я обязан добиться именно такого решения".
С виду это про ответственность и высокие стандарты. На практике это часто про тотальный контроль, лишние конфликты и дорогостоящий расход энергии.
Со временем, анализируя каждый цикл работы, своё состояние и ощущения, я начал понимать: дело не только в моём перфекционизме. Есть ещё системные факторы, которые добивали.
Невидимая работа: споры, метрики и "чайка-менеджмент"
1. Переговоры с заказчиком - скрытые битвы за чужое здоровье
Одна из моих задач - не допускать переработок. Звучит как простой флажок: "берегите людей".
В реальности это означало регулярные разговоры с заказчиком в стиле:
"Нет, мы не можем впихнуть ещё две задачи в этот спринт - команда уже на полной загрузке".
"Нет, за эти сроки мы не успеем без потерь по качеству или без переработок".
Заказчику, естественно, нужно быстрее, больше и желательно вчера. Он давит - я отбиваюсь. Команда чаще всего даже не знала, сколько таких "мини-боёв" происходило за их спиной.
Каждый такой разговор - отдельный энергетический расход, который не попадёт ни в один отчёт. Ментально это ощущается так, как будто ты стоишь в дверях и не пускаешь в комнату пожар, а потом сам кашляешь от дыма.
В результате команда не выгорела - а я накапливал усталость, которую нельзя закрыть "одной отгулянной пятницей".
2. Странные метрики "вовлечённости" сверху
В какой-то момент у руководства возникло желание измерять моё "участие" в работе. Формальной метрикой выбрали количество проведённых мной код-ревью. Причём не только в своей команде, а в целом по отделу.
Вроде логика проста: много ревью - значит, руководитель в теме, контролирует качество.
Проблема в том, что у меня в команде были сильные разработчики, чьё ревью объективно ценнее моего: они с головой в контексте, глубже понимают конкретный модуль. Моя фактическая зона ответственности - не вмешиваться туда, где и так всё в порядке, а убирать блокеры, решать конфликт интересов, выстраивать процессы.
Я пытался объяснять: "Моя работа - не дублировать ревью ребят, а создавать условия, при которых ревью вообще работают и не превращаются в формальность". В ответ кивали, соглашались - а через месяц возвращались к прежней схеме и снова спрашивали цифры по ревью.
Это рождало особый вид усталости: не от самой работы, а от бесконечных объяснений того, что кажется очевидным. Ты как будто каждый раз заново доказываешь, что твоя роль - не "старший программист", а менеджер.
3. "Чайка-менеджмент" как негласный стандарт
Периодически сверху просачивалось невысказанное, но ощутимое ожидание: руководитель должен быть "заметен" в процессах.
Влетать в обсуждения, комментировать каждое важное решение, активно проявляться на всех совещаниях, демонстрировать "присутствие". Мне в пример приводили одного руководителя, который работает по 14 часов в день, участвовал в десятках встреч, читал отчёты по маркетингу, спорил с аналитиками, проверял задачи разработчиков.
Посыл был простой: "Вот это настоящий руководитель. Везде успевает, всё держит под контролем".
Проблема в том, что такая модель делает из менеджера не точку ясности, а постоянный источник шума. Люди перестают принимать решения сами, потому что привыкли, что в любой момент сверху прилетит комментарий, правка или новый вектор.
А для самого менеджера это превращается в бесконечный марафон без остановок. Чтоб быть "заметным", ты начинаешь влазить туда, где твоё участие по факту не нужно. И вот уже не понимаешь, чем именно ты сегодня занимался, кроме как "был в процессе".
"Беда только в твоей голове?" - нет, но голова всё равно решает много
Один из самых опасных вопросов, который я себе задавал:
"Может, проблема только во мне? Может, я просто не тяну, перегибаю, слишком остро реагирую?"
С одной стороны, это честный вопрос. Да, часть выгорания - всегда про личные установки:
- неумение остановиться;
- привычка всё контролировать;
- внутренняя установка "если я не выложился на 120%, значит, сделал плохо";
- страх показать слабость или усталость.
С другой стороны, было бы наивно всё сваливать только на психику. Есть вполне конкретные системные факторы:
- культура "героизма" и 14-часовых рабочих дней;
- странные метрики, которые не отражают реальной ценности работы;
- постоянное давление заказчика без твёрдой позиции компании;
- отсутствие чёткого понимания, где заканчивается зона ответственности менеджера.
Выгорание - это всегда комбинация. Личных особенностей и среды.
Важно признать и то, и другое:
- да, кое-где я перегибал с контролем и перфекционизмом;
- да, система поощряла именно такое поведение и не предлагала здоровых границ.
Что я пробовал - и что не сработало
По мере нарастания усталости я предпринимал разные попытки "спасти ситуацию по-быстрому".
1. Жёсткое планирование времени.
Я пробовал ставить себе предел: после 19:00 - не отвечать в мессенджерах, не лазить в трекер задач, не думать о работе. В реальности голова продолжала крутить незакрытые вопросы. Я физически был дома, но ментально - всё ещё в спринте.
2. Максимальная структурность.
Я завалил себя инструментами: таск-менеджеры, календари, приоритеты, таймбоксы на встречи. Это убрало часть хаоса, но не решило корневую проблему - перегруженность ответственностью и внутренний запрет что-то "отпустить".
3. Пытаться "ставить себя на первое место".
Я честно пробовал говорить себе: "Твоё состояние важнее, чем идеальный процесс". Но без изменений в системе и роли это превращалось в красивый лозунг, который рушился при первом же аврале или конфликте.
4. Хобби, спорт, "разгрузка" после работы.
Да, это помогало не свалиться окончательно, но не отменяло того факта, что утром я возвращался в тот же контекст с теми же проблемами. Хобби лечит симптомы, но не саму причину.
Что действительно начало менять ситуацию
Первая серьёзная сдвижка началась не с отпусков и не с "нового планировщика", а с пересборки роли и ожиданий - своих и чужих.
1. Признать, что я не обязан быть фильтром всего.
Сначала это звучит почти крамольно: "Команда может столкнуться с давлением заказчика, и это не конец света". Я начал осознанно в некоторых ситуациях выводить людей на прямой контакт, заранее готовя их к переговорам и помогая выработать аргументацию. Это снижало нагрузку на меня и одновременно прокачивало их.
2. Определить, где качество действительно критично, а где - нет.
Мы ввели для себя неформальное правило:
- есть зоны, где мы требуем максимального качества (безопасность, данные, критичная логика);
- есть зоны, где "достаточно хорошо" допустимо (интерфейсы админок, внутренние тулзы, вспомогательные скрипты).
Это снизило уровень моей внутренней тревоги: не каждый компромисс - катастрофа.
3. Сделать часть "невидимой работы" видимой.
Я начал аккуратно проговаривать наверх и в сторону заказчика, что входит в мою нагрузку помимо формальных метрик: переговоры, управление ожиданиями, решение конфликтов, профилактика выгорания в команде. Не в формате жалобы, а в формате сухого описания фактов.
Где-то это вызвало уважение, где-то - пересмотр ожиданий. Не везде, но местами стало проще аргументировать отказ от бессмысленных метрик вроде "количество ревью ради количества".
4. Снизить планку перфекционизма к себе как к менеджеру.
Я перестал считать каждую несовершенную ретроспективу личным провалом. Иногда встреча просто "нормальная", а не "прорывная" - и это тоже ок. Не каждый 1:1 должен заканчиваться откровениями и инсайтами. Не каждая неделя обязана приносить мегапрорыв в процессах.
Что можно сделать, чтобы не повторить мой путь
Если вы уже в похожем состоянии - или чувствуете, что идёте к нему, - есть несколько шагов, которые стоит продумать заранее.
1. Ясно очертить границы ответственности.
Прямо выписать: за что вы отвечаете лично, а что - зона команды, заказчика, компании. Всё, что не в вашей зоне - не ваш постоянный груз. Помогать - да. Нести на себе - нет.
2. Выстроить честный диалог с командой.
Не только спрашивать "как вы себя чувствуете", но и говорить: "Сейчас я сам на пределе, мне важно, чтобы вы где-то взяли на себя больше". Многие готовы, если видят честность, а не "героический" фасад.
3. Отказаться от роли вечного щита.
Иногда полезно осознанно дать команде столкнуться с давлением и помочь им научиться его выдерживать. В долгую это лучше, чем бесконечно закрывать их собой и выгорать первым.
4. Проговорить абсурдные метрики.
Если сверху спускают показатели, которые не коррелируют с реальной пользой - как минимум обозначьте это. Возможно, услышат не сразу, но если молчать, система будет считать такие правила нормой.
5. Регулярно оценивать своё состояние как рабочий показатель.
Ваше выгорание - не личный "косяк", а риск для команды и результатов. Уставший, раздражённый, опустошённый менеджер - это снежный ком проблем через пару месяцев. Состояние - такая же метрика, как velocity.
Вместо вывода
История про "я берег команду, но выгорел сам" - не про благородную жертву. Это скорее про искажённую модель ответственности: когда менеджер берёт на себя слишком много - потому что так проще, привычнее, так его учили или так "принято" в компании.
Можно бесконечно чинить процессы, вводить новые доски, оптимизировать спринты и затягивать гайки. Но пока руководитель считает нормой игнорировать собственные пределы ради чужого комфорта, система всё равно будет выталкивать на обочину именно его.
Забота о команде без заботы о себе - путь к тому, что однажды в пятницу вечером вы будете смотреть на идеальный спринт и понимать:
да, все в порядке. Кроме вас.
И лучше задуматься об этом задолго до того момента, когда выключать захочется уже не только мессенджеры, но и всё остальное.
