# Как провести первые 90 дней в роли менеджера

> В первые 90 дней в роли менеджера нужно перестроить календарь, четко делегировать работу и следить за метриками здорового перехода.

Первые 90 дней в роли менеджера не должны превращаться в затянувшееся доказательство того, что вы по-прежнему хорошо справляетесь с работой индивидуального специалиста. Теперь вам предстоит управляемая передача результата: раньше он зависел от ваших рук, а теперь должен складываться из ясных приоритетов, качественных решений и самостоятельных действий сотрудников. Если вы остаетесь самым быстрым инженером в каждом обсуждении, команда может выглядеть занятой, хотя ее реальная пропускная способность постепенно сжимается вокруг вас.

Переход проходит успешно, когда календарь соответствует новой работе, у делегирования есть четкие границы, а команда с каждым месяцем меньше зависит от вашего прямого вмешательства. Это бывает непривычно, потому что видимые доказательства работы меняются. Слитый пул-реквест легко показать. Решение, которое избавило четырех человек от недели переделок, заметить труднее, но теперь оно тоже входит в ваш результат.

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

## Теперь результат вашей работы создают другие

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

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

Разделяйте технический контакт и техническую ответственность. Контакт означает чтение проектных документов, участие в отдельных ревью, разбор сбоя вместе с инженером или вопрос о том, выдержит ли предложенная граница следующий релиз. Ответственность означает владение планом реализации, принятие повседневных архитектурных решений и роль человека, без одобрения которого нельзя внести изменение. Сохраняйте контакт там, где он улучшает ваши оценки. Передавайте ответственность везде, где ее разумно может нести другой человек.

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

В первую неделю составьте короткий договор о роли со своим руководителем. Укажите результаты, за которые отвечаете вы, решения, которые остаются уровнем выше, состояние унаследованной команды и доказательства, ожидаемые через 30, 60 и 90 дней. Если руководитель говорит только «сделай команду эффективной», попросите примеры. Речь о предсказуемых поставках, меньшем числе сбоев, готовом плане найма, более ясных продуктовых решениях, сокращении затрат или более сильной технической ответственности? При расплывчатой задаче каждый срочный запрос становится вашим приоритетом.

## Перестройте календарь вокруг решений и развития людей

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

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

Используйте бюджет времени вместо идеального расписания на каждый день. На раннем этапе неделя руководителя одной инженерной команды может примерно распределяться так:

- встречи один на один и развитие сотрудников: 20% в начале и 20% к 90-му дню;
- продуктовые и технические решения: 25% в начале и 20% к 90-му дню;
- координация между командами: 20% в начале и 15% к 90-му дню;
- планирование и письменные итоги: 15% в начале и 20% к 90-му дню;
- технический контакт и свободный резерв: 20% в начале и 25% к 90-му дню.

Эти цифры задают ограничения, а не универсальные цели. Команде в квартале с частыми сбоями нужен больший резерв. Новой команде может потребоваться больше развития. Полезно проверить, соответствует ли календарь текущему риску команды. Если половина недели уходит на сбор статусов, сломана система отчетности. Если технический контакт постоянно разрастается, потому что каждый проект требует вашего ревью, сломано делегирование.

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

Часы для открытых вопросов могут сократить число прерываний, но не превращайте их в стену. Перенесите в предсказуемые окна обычные вопросы по архитектуре, несрочные согласования и разговоры о развитии. Оставьте открытым путь для эскалации рисков продакшена, вреда людям, проблем безопасности и решений, задержка которых остановит несколько сотрудников. Доступ к вам должен быть понятным, а не редким.

Отказ от встречи тоже может стать делегированием. Назовите человека, который отвечает за результат, сообщите, что нужно получить после встречи, и разрешите ему выбрать путь. Фраза «Майя отвечает за границу API. Пришли мне решение и нерешенные риски к четвергу» передает полномочия. Фраза «Я не смогу прийти, держите меня в курсе» заставляет всех ждать невидимого одобрения.

## Встречи один на один должны давать честный сигнал

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

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

Задавайте вопросы, которые вскрывают конкретное состояние. «Что сейчас отнимает больше сил, чем должно?» часто находит процессный долг. «Какого решения ты ждешь?» показывает заблокированные полномочия. «С чем в текущем плане ты не согласен?» делает несогласие безопаснее. «Что в следующем месяце должно перейти от меня к тебе?» превращает развитие карьеры в рабочее изменение. Общий вопрос «Как дела?» обычно получает такой же общий ответ.

Не откладывайте корректирующую обратную связь до личной встречи. Дайте ее вскоре после события, наедине, назовите наблюдаемое поведение, его последствия и ожидаемое изменение. На регулярной встрече проверьте, понял ли вас человек и как идет работа над изменением. Неожиданная критика во время планового разговора о карьере учит людей бояться приглашения в календаре и скрывать проблемы, пока не готова защита.

Частота встреч должна зависеть от потребности. Раз в неделю разумно встречаться в период перехода, с новыми сотрудниками и с теми, кто взял незнакомую область. Опытный и стабильный инженер может предпочесть встречу раз в две недели, но не сокращайте частоту только потому, что разговоры проходят легко. Легкость может означать доверие. Она также может означать, что оба обходят полезные темы. Оценивайте встречу по качеству информации и договоренностей, а не по приятным ощущениям.

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

## Делегирование начинается с письменного договора

Делегирование работает, когда владелец знает ожидаемый результат, границы, полномочия, контрольные точки и критерий завершения. Раздача задач без этих элементов только распределяет работу. Все скрытые решения по-прежнему держит менеджер, который превращается в узкое место при первой же неоднозначности.

Для работы крупнее обычной задачи используйте короткий договор о делегировании:

> **Результат:** Что должно стать правдой после завершения работы?
> **Владелец:** Один человек, который принимает повседневные решения и сообщает о состоянии.
> **Границы:** Бюджет, срок, технические ограничения и уже зафиксированные варианты.
> **Полномочия:** Решения, которые владелец принимает сам, обсуждает с другими или эскалирует.
> **Контрольные точки:** Даты или события для проверки риска, а не каждого промежуточного действия.
> **Готовность:** Доказательства результата, включая запуск и дальнейшую эксплуатационную ответственность.

Допустим, вы делегируете миграцию сервиса. Фраза «перенеси обработчик платежей в этом квартале» не отвечает на вопросы о простое, восстановлении данных, зависимостях и праве менять график. Хороший договор разрешает владельцу выбрать реализацию и порядок запуска, требует обсудить сверку данных с финансовыми операциями и предписывает эскалацию любого плана с риском потери принятых событий или превышения одобренного бюджета инфраструктуры. Контрольная точка наступает после тестовой миграции, а не после каждого пул-реквеста. Работа готова, когда трафик переведен, у оповещений есть владелец, откат проверен, а для старого пути принято решение с датой отключения.

Полномочия должны соответствовать ответственности. Нельзя объявить человека ответственным за поставку, оставив у себя все решения о людях, объеме и технической реализации. Он либо будет ждать вас, либо примет решения и позже узнает, что его ответственность была фикцией. Обозначайте границу прямо, особенно с опытными инженерами, которые могут принять вежливое предложение за приказ, потому что вы влияете на оценку их работы.

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

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

Делегирование не заканчивается передачей работы. Публично назовите владельца, перенаправляйте ему соответствующие вопросы и поддерживайте его решения в согласованных границах. Если коллеги продолжают спрашивать вас, а вы продолжаете отвечать, частное назначение владельца ничего не значит.

## Соотносите ответственность с готовностью, а не с уверенностью

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

Используйте четыре уровня полномочий и называйте их обычными словами. На первом уровне человек исследует варианты и дает рекомендацию, а решаете вы. На втором он принимает решение после консультации. На третьем принимает решение и сообщает вам. На четвертом полностью отвечает за область и эскалирует только заранее оговоренные исключения. Скажите человеку, какой уровень действует. Многие сбои делегирования возникают, когда менеджер подразумевает третий уровень, а инженер думает, что действует первый.

Передавайте полномочия по одному классу решений за раз. Человек может отвечать за способы реализации до того, как получит право давать продуктовые обещания. Он может вести устранение сбоя до того, как возьмет весь процесс разбора инцидентов. Так вы наблюдаете за его решениями, не превращая каждую развивающую задачу в испытание с высокими ставками. Если результат слабый, сузьте полномочия, добавьте более раннюю контрольную точку или уменьшите размер решения. Не забирайте всю работу молча.

Для развивающей задачи нужен допустимый запас ошибок в обычном смысле, а не метрика надежности. Определите, какие ошибки можно исправить, какую задержку выдержит проект и при каком условии вы вмешаетесь. Расскажите об этих пределах. Люди не научатся принимать решения, если защищать их от любых последствий, но они также не смогут учиться на сбое, который угрожает выплате зарплат, данным клиентов или договорному обязательству.

Осторожнее со спасением. Когда владелец приносит проблему, сначала попросите его назвать причину, варианты и рекомендацию, а потом предлагайте свое решение. Если время позволяет, дайте ему провести восстановление. Перехват работы награждает позднюю эскалацию облегчением и учит команду, что неприятный финал принадлежит менеджеру. Поддержка может означать снятие зависимости, поиск контекста или помощь в формулировке решения, пока владелец остается на виду.

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

## Метрики должны показывать зависимость от вас

Метрики перехода должны показывать, способна ли команда работать с меньшим управленческим трением, а не общую занятость людей. Число задач и часов онлайн плохо измеряет результат, потому что оба показателя могут расти, пока поставка становится менее предсказуемой. Измеряйте поток работы, задержку решений, ответственность, качество и сигналы от команды с контекстом, который объясняет изменения.

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

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

Не сводите их в одну оценку. Составной балл скрывает причину изменения и провоцирует манипуляции. Команда может сделать поставки предсказуемее, избегая сложной инфраструктурной работы, или снизить число инцидентов, выпуская меньше изменений. Читайте показатели вместе и обсуждайте с командой причинную историю.

Добавьте два коэффициента, относящихся к переходу. Сначала считайте, сколько повседневных решений потребовало вашего прямого одобрения и сколько решений названные владельцы приняли в своих границах. Затем разбирайте эскалации: слишком поздние, своевременные и излишне ранние. Ноль эскалаций не должен быть целью. Ноль может означать, что команда скрывает риск. Нужен более ранний сигнал о серьезных проблемах и меньше запросов на одобрение обратимых решений.

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

Опросы помогают только тогда, когда вы можете действовать по ответам и защищать откровенность. Короткое регулярное утверждение вроде «я знаю, кто решает при конфликте приоритетов» может найти неясность, но в маленькой команде ответы иногда легко сопоставить с людьми. Обсудите этот риск до сбора данных. Качественные наблюдения со встреч один на один, ретроспектив и повседневной работы могут оказаться безопаснее формального опроса.

Когда я сократил операционную команду с 25 человек до двух инженеров, усиленных ИИ, сохранив объем работы и бесперебойность, важным показателем была не активность на человека. Нужно было понять, делают ли ответственность, автоматизация и эксплуатационная обратная связь маленькую команду жизнеспособной. Тот же принцип действует для нового менеджера: измеряйте, переносит ли рабочая система нагрузку, а не количество движений руководителя.

Никогда не применяйте показатели перехода для рейтинга сотрудников. Они диагностируют командную систему и вашу работу менеджера. Если решения замедлились, потому что продуктовый руководитель не устраняет конфликт приоритетов, подсчет результатов инженеров не поможет. Назначайте владельца для каждого исправления и удаляйте метрики, которые не меняют ни одного решения.

## В первые 30, 60 и 90 дней нужно вести себя по-разному

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

В дни с 1-го по 30-й изучите работу и людей. Прочитайте текущие планы, разборы инцидентов, архитектурные решения, обязательства перед клиентами и недавние цели сотрудников. Встретьтесь с каждым прямым подчиненным и партнерами, которые зависят от команды. Выясните, где на самом деле принимаются решения, потому что это место часто не совпадает с организационной схемой. Сохраняйте работающие ритуалы, если они не причиняют явного вреда и не блокируют обязательства.

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

В дни с 31-го по 60-й передавайте ограниченные области ответственности. Пишите договоры о делегировании для существенной работы, отдавайте ведение встреч подходящим владельцам и фиксируйте первую базовую линию показателей. Давайте обратную связь по наблюдаемому поведению и спрашивайте, как люди оценивают скорость ваших ответов, ясность и характер вмешательств. В это же время нужно честно заняться унаследованными проблемами с результативностью сотрудников. Соберите факты, назовите ожидания, предложите поддержку и следуйте правилам компании, а не несите смутное беспокойство в четвертый месяц.

К 60-му дню у каждой постоянной области должен появиться названный владелец или ясная причина, по которой она остается у вас. Команда должна знать, какие решения требуют консультации, а какие нет. Покажите своему руководителю найденные риски, уже сделанные изменения и вопросы, для которых нужны полномочия или ресурсы выше вашего уровня.

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

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

На 90-й день представьте факты вместо победной речи. Покажите, чем теперь владеет команда, где поток ускорился или замедлился, какие риски остались, как обратная связь изменила ваше поведение и что потребуется в следующем квартале. Убедительный обзор содержит неприятные факты. Если поставка замедлилась, пока инженеры учились ответственности, скажите об этом и объясните, приводит ли вложение к более качественным решениям.

## Здоровый переход тоже может казаться медленным

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

Представьте нового менеджера, который сохранил ответственность за конвейер развертывания из-за чувствительности релизов. Инженеры готовят изменения, но менеджер одобряет конфигурацию, присутствует на каждом релизе и управляет откатом. Несколько недель команда выполняет сроки. Затем менеджер проводит два дня на встречах по планированию. Релиз ждет, следующее изменение встает за ним, а инженер пытается компенсировать задержку, объединяя больше изменений в следующем окне. Риск вырос, потому что менеджер пытался контролировать его лично.

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

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

Будьте готовы к эмоциональному трению. Бывшие коллеги могут проверять, влияет ли дружба на решения. Опытный инженер может решить, что его обошли. Вы можете скучать по ясному удовлетворению от законченной технической работы и принять этот дискомфорт за доказательство того, что управление вам не подходит. Обсуждайте конфликты прямо, объясняйте критерии решений и судите о роли после практики реальной работы, а не во время одновременного исполнения двух должностей.

Не нужно терпеть роль, которая вам не нравится. Некоторые отличные инженеры возвращаются на путь индивидуального специалиста, поняв, что предпочитают прямую техническую ответственность. Это разумное решение, если организация уважает оба карьерных пути. Первые 90 дней должны дать достаточно фактов, чтобы отличить непривычность от настоящего несовпадения с ролью.

## Завершите переход, убрав себя из обычного потока

К 90-му дню повседневная работа должна идти через названных владельцев и ясные правила, а не через вашу доступность. Кадровые решения, конфликты приоритетов, обязательства между командами и риски за пределами делегированных границ останутся у вас. Вы больше не должны быть маршрутизатором по умолчанию для обычных вопросов об архитектуре, релизах и статусах.

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

Задайте каждому прямому подчиненному три конкретных вопроса: какое решение ты теперь можешь принимать, хотя три месяца назад не мог? Где ты все еще ждешь меня? Какой контекст или доступ позволит тебе взять больше ответственности? Сравните ответы с журналом зависимости и показателями. Расхождение полезно. Если вы считаете ответственность переданной, а команда думает, что одобрение осталось у вас, поведение людей последует за их убеждением.

Затем выберите следующее ограничение. Им может оказаться слабое взаимодействие с продуктовой командой, перегруженный старший инженер, ненадежные данные о поставке, отсутствие эксплуатационного владельца или отложенная проблема с результативностью сотрудника. Назначьте одного ответственного, дату решения и точку проверки. Второй квартал должен начинаться с системной проблемы, а не с удлиненного личного списка задач.

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