Миф о плане адаптации на 30, 60 и 90 дней: честная ретроспектива после полугода работы инженерным менеджером

Полгода назад, после девятимесячного перерыва в карьере, я устроился менеджером инженерной команды (Engineering Manager). Это уже моя четвёртая руководящая должность, но впервые я возглавил уже сформированную команду, а не получил повышение внутри компании.

Мне много раз говорили, что первый месяц нужно «только слушать и учиться».

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

В этой статье хочу честно разобрать собственный опыт:

• Идеальный план, который развалился в первый же день

• Как я загнал команду в тупик

• 21 открытый тикет??? Что?! 

Идеальный план, который провалился в первый же день

До выхода на работу у меня был ОЧЕНЬ чёткий план.

Ещё на заключительных собеседованиях, а затем и после подписания оффера я всем говорил, что хочу первые 6–8 недель спокойно разбираться в кодовой базе и даже пару недель поработать в техподдержке. Мне казалось, что это отличный способ освоиться на новом месте: я смогу лучше понять техническую сторону проекта и со стороны понаблюдать за работой команды, прежде чем официально приступлю к руководству.

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

Но хватило буквально пары разговоров, чтобы я понял: план совершенно никуда не годится…

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

И вот что выяснилось. За три дня до моего выхода команду перевели в другое подразделение, перебросили на совершенно новый проект и назначили нового продакт-менеджера. К тому же все семеро рассказали, что последние полгода выдались непростыми. У них не было руководителя, никто не проводил встречи 1:1 (хотя формально они подчинялись директору), а сами семь инженеров работали над четырьмя совершенно не связанными между собой проектами. Они почти перестали ощущать себя командой, и им этого очень не хватало.

А потом я узнал, что по плану они должны были и дальше формально подчиняться прежнему директору (с которым практически не общались), а оперативным управлением совершенно новым проектом должен был заниматься новый директор (который ещё не был в курсе происходящего)…

Стало совершенно очевидно, что уйти с головой в код и отстраниться от всего остального было бы большой ошибкой.

Команда оказалась гораздо опытнее тех, с которыми я привык работать. В ней были бывший инженерный менеджер (теперь Staff Engineer), ещё два Staff Engineer, два старших инженера и два инженера уровня Middle. С технической стороной у них всё было отлично, и моя помощь там не требовалась.

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

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

Было наивно строить конкретные планы, не разобравшись сначала в реальной ситуации. Все эти рекомендации по адаптации на первые 30, 60 и 90 дней хороши, но у каждой команды свои обстоятельства. Думаю, до выхода на работу я слишком много рассказывал о своём «плане технического погружения».

Хорошо хотя бы то, что я сумел быстро перестроиться, хотя понимал, что не всем это понравится (мой директор предпочёл бы, чтобы я сначала получше разобрался в технической стороне проекта). Пришлось немного настоять на своём, но я был уверен, что поступаю правильно.

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

Как я загнал команду в тупик

Первую общую встречу команды мы провели в конце моего первого месяца. Я предложил обсудить вообще все командные процессы: продолжительность рабочих циклов, периоды передышки (cooldown), ежедневные созвоны и общие встречи.

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

Один из опытных инженеров вспомнил, что раньше они называли спринты в честь десертов и приносили эти десерты на демо. Мы решили возродить традицию, но вместо десертов выбрать коктейли и снова начать с буквы A. Спринт A стал Aperol Spritz, спринт B — Bloody Mary и так далее.

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

А я практически ничего не понимал. В самой работе я совсем не разбирался. Большая часть разработки велась на Ruby on Rails, с которым я раньше никогда не работал. Из технических обсуждений я понимал от силы процентов 30.

К концу спринта казалось, что до завершения осталось совсем чуть-чуть. Поэтому мы (точнее, в основном я) решили, что трое инженеров продолжат работу во время недельной передышки, чтобы наконец всё доделать. Ведь финиш был так близко!

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

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

И я благодарен ему за этот разговор. Мне очень хотелось, чтобы у нас поскорее появились первые успехи, поэтому я настойчиво искал минимальный объём работ, который позволил бы хоть что-нибудь выпустить. Но в итоге все постоянно чувствовали, что не успевают и что на них давят.

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

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

Что?! 21 открытый тикет???

Примерно через два месяца у меня наконец появилось время перевести дух.

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

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

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

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

За этот день мы закрыли 18 тикетов, причём несколько проблем устранили в корне, а не просто залатали временными исправлениями. (Кто-то даже выиграл 20 долларов в лотерею.)

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

Спустя два месяца я переключился с выполнения задач на клиентов и поддержку.

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

А потом всё началось заново

Четыре месяца пролетели незаметно. Сначала я сосредоточился на людях, затем на выполнении задач, а потом на поддержке. Постепенно всё стабилизировалось, и мы нашли свой ритм. У каждого появился человек, с которым можно было обсудить проблемы, все понимали, чего от них ждут. Мы снова стали командой, со своей культурой, традициями и даже названиями коктейлей:)

А потом случились две вещи:

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

• У нас с женой родился второй сын, и я ушёл в запланированный отпуск по уходу за ребёнком на месяц.

Я вернулся несколько недель назад и теперь снова подстраиваю свой подход под новые обстоятельства. План, который я составил полгода назад, ещё до выхода на работу, оказался бесполезным. И если бы я составил новый план сейчас, скорее всего, уже через несколько недель он тоже потерял бы смысл. Единственное, что действительно работало, — внимательно следить за происходящим, иногда слишком резко менять курс, а потом прислушиваться, когда кто‑нибудь говорил, что я перегнул палку:)

Напоследок

Постоянные перемены становятся реальностью для всё большего числа менеджеров. Я привык к стабильной работе: одни и те же инженеры, примерно одни и те же направления, привычный распорядок. Но готов поспорить, что в 2026 году и дальше такая стабильность будет встречаться всё реже. Слишком быстро меняются и технологии, и сами компании. Поэтому нам нужно постоянно подстраиваться под потребности своих команд.

И ещё: не бойтесь иногда нарушать представления о том, «как должно быть». Мне не раз говорили, что первые 30 дней на новой работе нужно только учиться и разбираться в происходящем. Я попробовал, но понял, что в моей ситуации это неправильный подход. И рад, что не стал упорно его придерживаться.

Что еще почитать по теме:

• Кто платит за ИИ‑продуктивность: почему выгорают middle‑инженеры

• Когда сотрудник тормозит команду: как говорить с ним прямо, но без давления

• Путь до CTO: как пройти его самому и помочь пройти другому

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

Предлагаем продолжить разбираться в этих вопросах на бесплатных открытых уроках:

• 19 ноября, 20:00. «Компетенции и личные навыки CTO». Записаться.

• 2 декабря, 20:00. «Хороший разработчик ≠ хороший тимлид: какие навыки придется перестроить». Записаться.

• 16 декабря, 20:00. «Почему команда не становится самостоятельной: ошибки тимлида в делегировании». Записаться.

Другие вебинары ноября собрали в дайджесте мероприятий.