Что перестать делать в первую неделю руководства: две ловушки, которые сломают команду

Разделение между кодом и командой: выбор нового тимлида — Первое решение нового руководителя: где провести эту неделю — в IDE или с людьми?

Вас назначили тимлидом. Первое утро. Вы открываете IDE по привычке, видите незакрытый pull request и думаете: «Сейчас быстренько допишу тесты, а потом уже займусь командой». Или открываете доску задач, видите хаос и решаете: «Нужно срочно внедрить нормальный agile, а то тут бардак».

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

Краткий ответ: перестаньте писать production-код и перестаньте менять процессы. В первые пять рабочих дней ваш единственный KPI — это пять честных разговоров один на один с членами команды. Всё остальное — откладывается.

Ловушка разработчика: почему production-код — ваш враг

Ловушка разработчика: попытка совместить код и управление — Когда новый тимлид продолжает коммитить в прод, он не успевает на свои же встречи

Первая ловушка — синдром «я должен остаться техническим». Вы боитесь потерять резкость навыков, боитесь, что вас перестанут уважать как профессионала, если вы не будете коммитить каждый день. Этот страх понятен, но в роли руководителя он токсичен.

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

Самое страшное происходит на 1:1. Вы отменяете встречи «потому что срочный баг» или приходите на них с головой в коде. Человек чувствует, что для вас важнее строка в IDE, чем его блокировка. Доверие не рождается.

Ловушка реформатора: срочная оптимизация без контекста

Ловушка реформатора: изменения без контекста — Новые процессы без понимания «почему так» воспринимаются как угроза

Вторая ловушка — желание сразу показать, что вы «пришли наводить порядок». Вы видите, что команда не пишет тесты, не ведет документацию, использует устаревший стек. И вы решаете: нужно срочно внедрить Definition of Done, обязательные code review и ежедневные стэндапы.

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

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

Почему это срабатывает: механизм разрушения

Баланс между технической работой и управлением людьми — В первую неделю чаша с людьми должна перевешивать

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

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

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

Контраргумент: а как же без кода и без изменений?

Возникает резонный вопрос: если я не пишу код, я потеряю квалификацию. Если я не меняю процессы, команда останется в болоте. Это правда, но не для первой недели.

Код можно и нужно писать, но не в продакшене. Архитектурные сессии, ревью сложных PR, написание прототипов для проверки концепций — это ваше поле. Вы остаетесь техническим экспертом, но не конкурентом своей команде за story points.

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

Еще один аргумент: «Но я должен показать результат быстро, иначе меня сочтут слабым». Это ловушка краткосрочной выгоды. Да, вы можете за неделю закрыть десять тикетов или внедрить новый CI/CD. Но если через месяц выяснится, что вы не понимаете мотивацию ключевого разработчика и он уйдет, или что новый CI сломал workflow тестировщиков, — ваш авторитет будет разрушен основательнее, чем если бы вы первую неделю просто наблюдали.

Практика: чек-лист первой недели

Чек-лист задач на первую неделю тимлида — Пять пунктов вместо коммитов

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

День 1-2. Ноль коммитов в prod-репозитории. Разрешите себе архитектурные обсуждения, ревью кода, парное программирование. Но не пушьте в мастер. Пусть команда видит, что вы доверяете им production.

День 1-5. Пять встреч 1:1. По 30-45 минут с каждым членом команды. Не отменяйте. Формат: 10 минут про их блокеры, 10 минут про их амбиции, 10 минут про то, что они хотели бы изменить в команде. Записывайте.

День 2-5. Дневник наблюдений. Три колонки: «Работает» (что команда делает хорошо без вашего участия), «Ломается» (где реальные узкие места), «Не понятно» (что требует уточнения). В конце недели у вас будет карта реальности, а не ваших предположений.

День 3. Встреча с продуктом/заказчиком без команды. Поймите, что для бизнеса значит успех этого проекта. Какие сроки критичны, какие фичи — must have. Это даст вам контекст для будущих решений.

День 5. Обратная связь. Скажите команде: «Я неделю наблюдал, ничего не меняя. На следующей неделе я приду с предложениями по улучшению, но сначала хочу проверить свои наблюдения с вами». Это покажет уважение и вовлеченность.

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

Канал «Тимлидство в моей голове» — практические кейсы и разборы: https://t.me/tl_in_my_head