Вчера вы были лучшим инженером в команде. Сегодня у вас пять подчинённых, конфликт между двумя из них, горящий дедлайн и ноль готовых решений в голове. В этой карте пошаговый маршрут на первые 90 дней в роли тимлида: что делать по неделям, какие ошибки не совершать и какими шаблонами закрыть типовые ситуации, чтобы заслужить доверие команды и бизнеса и не потеряв при этом технические навыки.
Карта собрана из моего опыта и из отдельных разборов в блоге. Везде, где тема раскрыта глубже, стоит ссылка на полную статью.
Перед стартом: главный сдвиг в голове
Раньше ваш результат измерялся вашим кодом. Теперь ваш результат = результат команды. Не воспринимайте изменение как повышение «инженера до старшего инженера», это смена профессии. Вы теперь руководитель. Ваша ключевая метрика теперь в другом: хороший тимлид не тот, кто больше всех коммитит в репу. Хороший тимлид это тот при ком команда даёт 1 + 1 = 11, а не 1 + 1 = 1 (об этой арифметике я писал в заметке про уровни тимлида).
У тимлида-новичка есть два здоровых страха:
- «Не справлюсь с людьми». Ведь раньше я отвечал за код, а теперь за конфликты, мотивацию и чужие ошибки.
- «Деградирую как инженер». Перестану писать код, отстану и через год меня никто не захочет нанять как инженера.
Облегчающая новость: управление и техническую глубину можно и нужно совмещать. Плохая новость в том, что это будет возможно только если осознанно распределять ваше время с первого дня.
Чего НЕ делать в первый месяц:
- «Сейчас как всё перепишем по-нормальному». Вы ещё не знаете, почему так сделано. Не делайте революций.
- Всех «построить» или, наоборот, стать «своим парнем», который ни о чём не просит. Не впадайте в крайности.
- Замкнуть на себя все решения, потому что «так быстрее и надёжнее». Так будет только хуже, в первую очередь для вас.
Дни 1–30: Слушать и понять
Главная задача первого месяца диагностировать. Не спешите вносить изменения в работу. Сначала собираете картину реальности: кто есть кто, как устроены процессы, чего ждёт бизнес. Без понимания контекста вы будете совершать решения вслепую и только ухудшать свою и без того сложную ситуацию.
Чек-лист первой недели
- Познакомиться лично с каждым членом команды (вводный 1-на-1, шаблон ниже)
- Получить необходимые доступы: репозитории, CI/CD, мониторинг, трекер, документация, документы, отпуска, планы и т.п.
- Узнать, перед кем вы отчитываетесь, по каким метрикам оценивают результат команды
- Изучить (если есть): онбординг-доки, последние ретро, открытые инциденты, техдолг-беклог
- Найти «исторический контекст»: кто в команде дольше всех, кого спрашивать «почему так» (это делается через людей или по истории git коммитов)
- Узнать календарь команды: какие регулярные встречи есть и зачем
- Зафиксировать текущие обещания бизнесу: что, кому и когда уже было обещано
Шаблон вводного 1-на-1 с каждым
Цель первой встречи понять человека. Постарайтесь, что бы говорил в основном он, а вы слушайте и записываете.
- Расскажи, над чем сейчас работаешь и что из этого тебе нравится больше всего?
- Что в команде/проекте устроено хорошо, что менять не стоит?
- Что тебя бесит или тормозит в работе прямо сейчас?
- Если бы была возможность, то что бы ты изменил в первую очередь?
- Куда ты хочешь расти в ближайший год?
- Как тебе удобнее получать обратную связь и как часто?
- Чего ты ждёшь от меня в новой роли?
После каждой встречи фиксируйте: что человек умеет, что его мотивирует, какие у него боли. Это основа будущих ИПР (здесь и далее Индивидуальный План Развития) и распределения задач.
Что измерить на входе
Зафиксируй факты того, как сейчас работает команда. Без оценочных суждений и только сухие факты. Нам необходима контрольная точка, чтобы через 90 дней оценить изменения:
- Как сейчас устроены планирование, дейлики, ревью, релизы.
- Где команда теряет время (повторяющиеся боли от сотрудников из 1-на-1).
- Какие ожидания у бизнеса и насколько они совпадают с реальностью команды.
❌ Ключевая ошибка 1-ого месяца: начать менять до того, как поняли. Новый тимлид, ломающий процессы «потому что на прошлом месте было лучше», быстро потеряет всё доверие. Сначала понимание, а потом изменения.
Дни 31–60: Закрепиться и наладить рутину
Итак, вы собрали контекст. Отлично. Теперь на основе наблюдений можно вносить изменения в регулярные процессы. Задача месяца: поставить предсказуемую работу команды, но так что бы не превращать себя в «ручного диспетчера».
Запустить регулярные 1-на-1
Страый формат встречи, но другая цель. Мы теперь не знакомимся, а создаём пространство про человека и для него. Ни в коем случае не превращайте встречу в «статус по задачам». Создайте среду для открытого и честного общения для роста сотрудника. Проводить примерно раз в 1–2 недели, закладывайте в календаре 1 час.
Шаблон регулярного 1-на-1:
- Как дела в целом? (5 мин, искренне, не формально)
- Что получилось / чем гордишься с нашей прошлой встречи?
- Что мешает, где нужна моя помощь?
- Обратная связь тебе от меня (по делу, без оценочных суждений)
- Обратная связь мне от тебя (что улучшить в моей работе)
- Договорённости: что каждый из нас сделает к следующему разу
Антипаттерн: 1-на-1 превращается в отчётность по задачам. Если это случилось, то фактически дублируете standup и тратите единственный, самый ценный и качественный канал доверия впустую.
Первые сложные разговоры
К этому моменту накопятся ситуации, требующие прямого разговора: кто-то срывает сроки, кто-то демотивирован, кто-то конфликтует. Не откладывайте, замолчанная проблема всегда дороже ошибки.
Структура и конкретные фразы разобраны в отдельной статье про то как давать негативную обратную связь. Короткий каркас разговора:
Факт → Эффект → Ожидание → Договорённость «На прошлой неделе релиз ушёл на стейдж на два дня позже (факт). Из-за этого смежная команда не успела с интеграцией (эффект). Мне важно, чтобы о риске срыва я узнавал заранее, а не в день дедлайна (ожидание). Давай договоримся, что при первом сомнении в сроке ты пишешь мне сразу (договорённость)».
Наладить базовые процессы
- Дейлик. Короткая встреча обсудить блокеры и синхронизироваться, не превращайте в ежедневный отчёт по задачам для тимлида.
- Планирование. Прозрачность приоритетов, создание в команде понимания, почему делаем именно это и именно в таком порядке.
- Разбор инцидентов без обвинений. Когда что-то ломается (в сервисах или процессах), ищем причину, а не виноватого. Метод «5 почему» помогает докопаться до системной причины вместо «Васян выкатил баг, Васян плохой».
Начать делегировать
Классическая ловушка новичка-руководителя — замкнуть всё на себя. Отдавайте задачи постепенно, начиная с тех, где ошибка не критична, а человек растёт. Делегирование не про то, что бы «скинуть задачу», а про то что бы передать ответственность вместе с контекстом и правом принимать решение.
Защищать команду и оценивать сроки
Вы являетесь буфером между бизнесом и командой. Причём в обе стороны. Бизнес хочет «быстрее», команда хочет «по-нормальному». Вы переводчик между ними и должны честно оценивать сроки. Помните, что переработки убивают скорость, а не повышают её — об этом я писал в разборе про то, как не сгореть от перегрузки задачами.
❌ Главная ошибка месяца 2: микроменеджмент или, наоборот, самоустранение. Две крайности: либо контролировать каждый коммит (команда перестаёт думать), либо «вы взрослые, разберётесь» (команда теряет направление). Граница проходит по результату и контексту: договоритесь о цели и критериях, а как — отдайте команде.
Дни 61–90: Влиять и расти
Итак, рутинные процессы работают, доверие появилось. Теперь вы переходите от «навести порядок» к «делать команду сильнее», а заодно и сохранять себя как инженера.
Первый цикл развития людей
На основе вводных 1-на-1 и наблюдений соберите для каждого индивидуальный план развития (ИПР): где человек сейчас, куда хочет, какие 2–3 конкретных шага сделать в ближайший квартал. Как растить людей через ситуационное лидерство — в статье про менторинг джуниор-разработчиков.
Каркас ИПР:
- Сейчас: какие навыки есть, на каком уровне (по 2-3 ключевым компетенциям)
- Цель на квартал: одна конкретная, проверяемая (не «стать лучше», а «провести одну фичу от дизайна до релиза самостоятельно»)
- Шаги: 2-3 действия с поддержкой от вас (задача, ревью, парная работа, обучение)
- Точка проверки: когда и как поймём, что цель достигнута
Как не потерять техническую экспертизу
Это второй страх тимлида-новичка. Страх, вполне реальный, кстати. Вот как защищаться:
- Участвуйте в архитектурных ревью и обсуждениях дизайна. Ваша технический опыт принесёт больше пользы команде. Пример правильных рассуждения о выборе архитектуры — монолит vs микросервисы.
- Не пишите код в критическом пути команды. Если релиз зависит от кода который вы должны написать, то «поздравлю»: вы стали бутылочным горлышком и плохим тимлидом одновременно.
- Берите технические задачи вне критического пути: инструменты, прототипы, сложные исследования. Так руки остаются «в коде», а команда не блокируется на вас.
Метрики команды: что измерять, а что под запретом
Измеряйте поток и результат, а не активность.
| Измерять стоит | Измерять нельзя (вредит) |
|---|---|
| Lead Time: от идеи до прода | Строки кода (LoC) |
| Частоту релизов | Число коммитов |
| Долю иницидентов | Часы «у компьютера» |
| Время восстановления после сбоя | Закрытые тикеты «на человека» как KPI |
Задача метрив в упрощении разговора как с командой, так и с бизнесом. Не используйте метрики как дубинка для отдельных людей (для этого есть другие способы и инструменты).
Ретроспектива своей работы
В конце 90 дней проведите ретро по себе: что из задуманного получилось, где вы скатывались в микроменеджмент или прятались в код, что команда говорит о вас на 1-на-1. Сравните с «нулевой точкой» из первого месяца.
❌ Главная ошибка месяца 3: забыть про себя. Новый тимлид так увлекается командой и процессами, что перестаёт спать и выгорает первым. Ваша устойчивость часть результата командной работы, а не только ваше личное дело.
Сводный пакет шаблонов
Всё, что нужно держать под рукой:
- Чек-лист первой недели — раздел «Дни 1–30».
- Шаблон вводного 1-на-1 — 7 вопросов на знакомство.
- Шаблон регулярного 1-на-1 — 6 пунктов ритма.
- Каркас сложного разговора — Факт → Эффект → Ожидание → Договорённость.
- Каркас ИПР — Сейчас → Цель → Шаги → Точка проверки.
- Таблица метрик — что измерять, а что под запретом.
Итог
Первые 90 дней про то, чтобы понять (месяц 1), стабилизировать (месяц 2) и начать улучшать (месяц 3). Не сломав доверие команды и не потеряв себя как инженера. Главный сдвиг в вашей голове. Поймите и примите, что теперь ваш результат измеряется результатом команды. Всё остальное — следствие.
Теги: