Вы только что стали тимлидом — или вот-вот станете. Вам говорят: «Осмотрись, войди в курс дела». Но через неделю уже спрашивают, почему команда не закрыла задачи по спринту. Через две — просят «навести порядок» в процессах. Через месяц — ждут видимых результатов.
Это классический конфликт: организация хочет быстрого эффекта, а новый тимлид ещё не понимает, что именно сломано и где вообще точка входа. Без структуры первые 90 дней превращаются в реактивный режим: тушишь пожары, но не строишь ничего устойчивого.
План 30–60–90 — не магический рецепт. Это каркас, который помогает расставить приоритеты и не делать всё одновременно. Ниже — адаптируемый шаблон для тимлида в инженерной команде.
Почему именно 90 дней и в чём логика деления
Подход «первых 90 дней» помогает разбить адаптацию на понятные этапы. Срок условный: в разных командах на знакомство, первые решения и закрепление договорённостей нужно разное время. Используйте три этапа как рабочую рамку, а не как обещание результата к определённой дате.
Для тимлида логика деления на три фазы такая:
- Первые 30 дней — слушать и понимать. Не менять, не «улучшать», не показывать экспертизу действием.
- С 31 по 60 день — формировать договорённости. Первые небольшие изменения, которые команда поддерживает, а не терпит.
- С 61 по 90 день — закреплять роль. Вы уже не «новенький», у вас есть позиция и система работы.
Деление условное. В стартапе с пятью людьми первая фаза может сжаться до двух недель. В корпорации с устоявшимися процессами — растянуться. Но принцип «сначала понять, потом действовать» работает везде.
Первые 30 дней: слушать, не ломать
Самая частая ошибка нового тимлида — прийти с готовыми решениями. «Я вижу, что у вас нет code review — сейчас введём». «Ретро проводите неправильно — переделаем». Это не плохие идеи сами по себе. Плохо то, что они появляются раньше понимания контекста.
Что реально важно сделать в первый месяц:
- Провести 1-on-1 с каждым участником команды. Не аттестацию, а разговор. Что человек считает работающим? Что мешает? Чего он ждёт от тимлида? Записывайте — не для отчёта, а чтобы не забыть паттерны.
- Понять неформальную структуру. Кто реальный авторитет в команде? Кто к кому ходит за советом? Это не всегда совпадает с грейдом.
- Разобраться в контексте продукта и бизнеса. Какие метрики важны стейкхолдерам? Что считается успехом релиза? Без этого любые технические решения будут в вакууме.
- Зафиксировать текущие процессы как они есть. Не как написано в вики, а как реально работает команда. Часто это разные вещи.
- Договориться с руководителем о ожиданиях. Что он хочет увидеть через 30, 60, 90 дней? Лучше спросить прямо, чем угадывать.
Результат первых 30 дней — не видимые изменения, а карта реальности: люди, процессы, боли, контекст.
С 31 по 60 день: первые договорённости
К этому моменту у вас есть картина. Теперь можно начать действовать — но точечно и с командой, а не вместо неё.
Типичные задачи второй фазы:
- Выбрать одну-две проблемы, которые команда сама называет болью. Не то, что кажется важным вам или вашему руководителю, а то, от чего устала команда. Это создаёт доверие: «тимлид слышит».
- Предложить изменение, а не ввести его. «Я слышал, что стендапы затягиваются. Давайте попробуем формат X две недели и посмотрим?» — это не то же самое, что «теперь стендап по-новому».
- Начать регулярные 1-on-1. Если их не было — ввести. Если были — сделать их предсказуемыми по формату.
- Прояснить зоны ответственности. Кто принимает технические решения? Как эскалируются блокеры? Где граница между тимлидом и архитектором, если он есть?
- Дать первую обратную связь. Не оценочную («ты делаешь плохо»), а поведенческую («я заметил X, это создаёт Y — давай обсудим»).
Ловушка второй фазы — попытаться исправить всё сразу. Команда устаёт от постоянных изменений не меньше, чем от отсутствия изменений. Два-три фокуса за месяц — нормально. Десять — перегруз.
С 61 по 90 день: закрепить роль
К третьему месяцу вы должны перестать быть «новеньким» в голове у команды. Это не значит, что все проблемы решены. Это значит, что у команды есть ответ на вопрос «кто наш тимлид и как с ним работать».
Что характеризует конец третьей фазы:
- Команда знает, с чем идти к тимлиду, а с чем — нет.
- Есть хотя бы один процесс, который изменился и работает лучше — и команда это признаёт.
- Тимлид понимает сильные стороны каждого и знает, кому что делегировать.
- Руководитель получает предсказуемые апдейты, а не узнаёт о проблемах случайно.
- Есть список того, что тимлид ещё не успел — и это нормально.
Последний пункт важен: 90 дней — не финиш. Это точка, где вы перестаёте адаптироваться и начинаете работать в полную силу. Незакрытые задачи на этом горизонте — не провал, а материал для следующего квартала.
Контраргумент: «У меня нет 90 дней»
Это реальное возражение. Иногда тимлид заходит в горящую команду: дедлайн через три недели, два человека уволились, продукт не работает. Какой план 30–60–90?
В кризисе буквальный календарь может не подойти. Но даже при срочном дедлайне полезно выяснить, что происходит, кто принимает решения и какой риск требует реакции первым. Сократите этап знакомства, сохранив сам разговор с командой и руководителем.
На первые разговоры один на один и согласование ожиданий стоит выделить время заранее. Их длительность зависит от размера команды и ситуации; важнее зафиксировать факты и договорённости, чем уложиться в универсальную норму.
Если контекст действительно экстремальный — сожмите фазы. Первая неделя вместо первого месяца. Но не пропускайте фазу понимания совсем: это единственное, что отличает осознанное управление от реактивного.
Сценарий разговора: как договориться об ожиданиях с руководителем
Один из самых недооценённых шагов первых 30 дней — прямой разговор с руководителем о том, что он ждёт. Вот рабочая структура для такого разговора:
Открытие:
«Я хочу убедиться, что мы одинаково понимаем, что значит успех для меня на этой позиции в первые три месяца. Можем поговорить об этом?»
Вопросы, которые стоит задать:
- «Что для тебя будет сигналом, что первые 30 дней прошли хорошо?»
- «Есть ли проблемы в команде, которые ты ждёшь, что я решу в первую очередь?»
- «Как ты предпочитаешь получать апдейты — и как часто?»
- «Где граница моей самостоятельности в принятии решений?»
Фиксация:
После разговора — короткое письмо или сообщение: «Резюмирую, как я понял договорённости: [список]. Если что-то не так — поправь».
Это не бюрократия. Это страховка от ситуации, когда через 60 дней выясняется, что вы оптимизировали не то, что было важно руководителю.
Итог: план как инструмент, не обещание
План 30–60–90 для нового тимлида — это не гарантия успешной адаптации. Это способ не потерять три месяца в реактивном режиме.
Три вещи, которые стоит сделать сегодня, если вы новый тимлид:
- Запланировать 1-on-1 с каждым участником команды в первые две недели.
- Поставить в календарь разговор с руководителем об ожиданиях — до конца первой недели.
- Завести простой документ (заметка, notion, что угодно) где фиксируете наблюдения — не выводы, а факты.
Остальное — итерации поверх этого фундамента.
Если тема адаптации нового тимлида актуальна, сохраните этот план и возвращайтесь к нему после первого месяца: пункты можно менять по мере того, как становится понятнее контекст команды.