Пять ошибок тимлида в первый месяц

Пять ошибок тимлида в первый месяц

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

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

Ошибка 1. Продолжать писать код вместо того, чтобы управлять

Самая частая и самая понятная ошибка. Вы хороший разработчик — именно поэтому вас и повысили. Код даёт немедленную обратную связь: написал, запустил, работает. Управление такой обратной связи не даёт неделями.

Поэтому новый тимлид берёт задачи из бэклога, закрывает тикеты, помогает с ревью — и чувствует себя продуктивным. Команда при этом остаётся без ориентиров: кто принимает решения по архитектуре? Кто разблокирует зависший PR? Кто поговорит с продактом о приоритетах?

Книга Камиллы Фурнье «The Manager's Path» прямо называет этот переход — от индивидуального вклада к управлению — одним из самых сложных в карьере инженера. Проблема не в том, что вы плохой менеджер. Проблема в том, что старая роль психологически безопаснее новой.

Контраргумент: «Но тимлид должен оставаться техническим, иначе потеряет авторитет». Это правда — частичная. Технический авторитет важен, но он поддерживается через ревью, архитектурные решения и наставничество, а не через личное закрытие задач. Если вы единственный, кто умеет делать X, это проблема команды, а не повод делать X самому.

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

Ошибка 2. Не проводить one-on-one в первые недели

«Мы и так общаемся каждый день на стендапе». Это не замена личного разговора. Стендап — публичное пространство, где никто не скажет: «Я не понимаю, куда мы движемся» или «Меня беспокоит, что Петя игнорирует мои комментарии в ревью».

Исследование Google в рамках программы re:Work показало, что регулярные встречи менеджера с каждым членом команды напрямую связаны с психологической безопасностью — а психологическая безопасность, согласно тому же Project Aristotle, оказалась наиболее значимым фактором эффективности команды из пяти изученных.

Первый месяц — это период, когда люди формируют представление о вас как о руководителе. Если вы не разговариваете с ними лично, они заполняют пробелы домыслами.

Контраргумент: «У меня нет времени на встречи с каждым». Если в команде пять человек и вы не можете найти 30 минут в неделю на каждого — это уже другая проблема: либо вы перегружены задачами (см. ошибку 1), либо команда слишком большая для одного тимлида.

Шаг: В первую неделю проведите короткие «знакомительные» one-on-one по 20–30 минут с каждым. Не отчёт о задачах — разговор. Три вопроса для старта: что сейчас идёт хорошо, что мешает работать, чего вы ждёте от меня как от тимлида?

Ошибка 3. Немедленно менять процессы

Новый тимлид видит проблемы — это хорошо. И хочет их немедленно исправить — это опасно. Первый месяц — не время для реформ. Это время для наблюдения.

Когда вы приходите и сразу меняете ретро, спринты, формат ревью или инструменты, команда воспринимает это как сигнал: «То, что мы делали раньше, было неправильным». Даже если изменения объективно полезны, они создают сопротивление — потому что люди не понимают контекст решения и не участвовали в нём.

Есть ещё один риск: вы можете не понимать, почему процесс именно такой. За любым «странным» решением может стоять история, которую вам ещё не рассказали.

Контраргумент: «Но если процесс явно сломан, молчать — значит соглашаться». Верно. Но есть разница между «я вижу проблему и хочу её обсудить» и «я пришёл и сразу всё переделал». Первое строит доверие, второе — разрушает.

Шаг: Первые четыре недели — режим наблюдения. Записывайте наблюдения и гипотезы, но не внедряйте изменения. На пятой неделе проведите ретроспективу с командой и предложите одно изменение — с объяснением и вопросом «как вы это видите?».

Ошибка 4. Не прояснять ожидания с руководителем

Вы знаете, чего ждёт команда. Но знаете ли вы, чего ждёт от вас ваш руководитель? Что значит «хорошо справляется» через три месяца? Какие решения вы принимаете самостоятельно, а какие согласовываете?

Большинство новых тимлидов не задают эти вопросы — неловко, кажется очевидным, «разберёмся по ходу». В результате через два месяца выясняется, что руководитель ждал роста скорости доставки, а тимлид фокусировался на качестве кода. Или наоборот.

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

Контраргумент: «Мой руководитель сам должен это объяснить». В идеальном мире — да. В реальном мире руководители тоже заняты и часто не формулируют ожидания явно, пока не возникает проблема. Ваша задача — инициировать этот разговор.

Сценарий разговора: «Хочу убедиться, что мы одинаково понимаем приоритеты. Можем ли мы договориться о трёх-четырёх критериях, по которым через 90 дней ты поймёшь, что я справляюсь? И отдельно — какие решения я принимаю сам, а какие согласовываю с тобой?»

Ошибка 5. Избегать сложных разговоров

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

Сложные разговоры не становятся легче от откладывания. Они становятся тяжелее — потому что накапливается контекст, растут ожидания, и чем дольше вы молчите, тем сильнее сигнал «тимлид это одобряет».

Первый месяц — лучшее время для сложных разговоров. У вас есть статус новичка: «Я только вхожу в роль и хочу сразу выстроить честную коммуникацию». Это окно закрывается.

Контраргумент: «Сначала нужно заработать доверие, потом говорить сложное». Доверие не предшествует честности — оно строится через неё. Команда видит, когда тимлид замалчивает очевидное. Это не воспринимается как дипломатия — это воспринимается как слабость или неискренность.

Шаг: Выберите один разговор, который вы откладываете прямо сейчас. Не самый сложный — но тот, что уже висит. Проведите его на этой неделе. Не с обвинением, а с наблюдением: «Я замечаю X. Как ты это видишь?»

Практический итог: чек-лист первого месяца

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

Вот минимальный чек-лист для первых четырёх недель:

• Неделя 1: провести знакомительные one-on-one с каждым членом команды (20–30 минут, три вопроса выше)
• Неделя 1–2: поговорить с руководителем об ожиданиях и границах полномочий
• Недели 1–4: наблюдать за процессами, фиксировать наблюдения — не менять
• Неделя 2: посчитать долю времени на код и осознанно начать её сокращать
• Неделя 2–3: провести один сложный разговор, который уже висит
• Неделя 5: предложить одно изменение процесса — с обоснованием и обсуждением

Ни один из этих пунктов не требует особых управленческих навыков. Они требуют только решения их сделать.

Если вы сейчас в этом переходе — или готовитесь к нему — практические кейсы и разборы выходят в Telegram-канале: Тимлидство в моей голове.