В tutu запустили школу тимлидов и начали ее не с мотивационных мантр, а с разбора того, на чем чаще всего сыплются новоиспеченные руководители. Ошибки начинающих руководителей здесь разобраны без романтики: лишние встречи, страх изменений, попытка быть одновременно лучшим разработчиком, психологом и щитом от бизнеса. Для русскоязычной IT-аудитории это полезный сигнал: управленческий онбординг в компаниях все чаще пытаются собирать как продукт, а не как набор случайных советов в курилке.
Об этом сообщает Habr / Карьера в материале Павла Баранникова, IT lead направления TutuCross в tutu.ru. По его словам, вводный урок для внутренней школы вырос из практической задачи: показать будущим тимлидам грабли заранее, до того как они начнут воспитывать команду через календарь, пинг и внезапные процессные реформы. Позже автор выступил с этим докладом на UlCamp26 и, судя по реакции аудитории, попал в нерв темы: проблемы оказались слишком узнаваемыми, чтобы списать их на частный случай одной компании.
Список типовых сбоев выглядит болезненно знакомо для любого, кто хоть раз наблюдал превращение сильного инженера в руководителя. Первый блок касается роли. Новый тимлид нередко продолжает жить так, будто его главная задача все еще писать код, закрывать баги и лично тащить технические решения. В мягком варианте это просто съедает время. В жестком превращает команду в арену, где руководитель конкурирует с сильнейшими разработчиками за статус главного эксперта. Баранников предлагает зафиксировать неприятный, но базовый факт: после перехода в руководящую роль человек меняет профессию. Да, техническая экспертиза остается важной. Но KPI уже в другом месте: синхронизация команды, приоритеты, delivery, обратная связь и работа с ожиданиями бизнеса.
Отсюда вытекает вторая группа проблем: границы и фокус. Если тимлид вырос внутри той же команды, его почти автоматически тянет в один из двух перекосов. Либо он остается «своим парнем» и боится включать управленческую оптику. Либо резко надевает начальственный мундир и начинает общаться так, будто вчерашние коллеги теперь его личный департамент. Оба сценария работают плохо. В первом случае рушится субординация и размывается ответственность. Во втором быстро сгорает доверие. Отдельная ловушка, о которой пишет автор, это неспособность говорить «нет». Новичку кажется, что любая входящая задача автоматически его задача. В результате он становится универсальным приемником чужих проблем, не успевает главное и тонет в хаотичном потоке встреч, сообщений и обещаний «посмотрю сегодня».
Практический рецепт в статье предельно земной. Во-первых, руководителю нужна карта ответственности команды: за что именно отвечает его контур, где он принимает решение, а где только консультирует. Во-вторых, нужен инструмент личной приоритезации, а не вера в память и адреналин. Баранников напоминает про простую схему с делением задач на срочные, среднесрочные и несрочные, а в качестве базовой рамки упоминает матрицу Эйзенхауэра. В-третьих, встречи нужно фильтровать без сантиментов. Сам по себе инвайт в календаре еще не доказывает, что без вас Вселенная схлопнется. Если вопрос решается в чате, делегируется или требует другого специалиста, руководитель должен это признать раньше, чем его календарь окончательно превратится в Tetris.
Еще один важный блок посвящен ответственности и коммуникациям. Здесь ошибки начинающих руководителей особенно дорого стоят, потому что быстро бьют не только по эффективности, но и по состоянию команды. Автор отдельно выделяет страх изменений: новый менеджер видит, что процессы скрипят, но боится трогать то, что «работало до него». Формально это выглядит как осторожность, по факту часто оказывается заморозкой проблем. При этом обратный перекос тоже знаком: человек начитался литературы по менеджменту, влюбился в процессы и начинает внедрять их ради самих процессов. Статья аккуратно возвращает разговор в скучную, но полезную плоскость: процесс ценен только пока помогает достигать результата. Если не помогает, значит, либо выбран не тот инструмент, либо его используют не по назначению.
В части people management автор не делает скидок интровертам и поклонникам тихой инженерной автономии. Игнорировать 1:1, избегать обратной связи и надеяться, что команда «сама как-нибудь поймет», не получится. Для руководителя это уже не вкусовщина, а часть работы. То же касается коммуникации с бизнесом. Тимлид становится контактным лицом по вопросам delivery, сроков и статуса задач, а значит должен уметь не только отвечать быстро, но и управлять ожиданиями: обозначать этапы, подсвечивать пробелы в постановке, проговаривать риски дедлайнов и, где возможно, дробить работу до MVP. Иначе команда будет жить в одной реальности, заказчик в другой, а виноватым по традиции окажется тот, у кого был доступ к календарю и созвону.
Отдельно любопытен финальный список «поглотителей времени» и календарных правил. Там нет никакой тайной магии, зато есть то, что в реальной управленческой жизни работает чаще модных фреймворков: не ставить встречи длиннее 45 минут без явной причины, оставлять между ними зазоры, не собирать людей «на всякий случай», не плодить слишком частые регулярки, резервировать обед и рабочие слоты в календаре. Это, возможно, звучит слишком просто для большой управленческой философии, но именно на таких мелочах обычно и строится разница между тимлидом, который управляет вниманием команды, и тимлидом, которого управляют уведомления.
Для рынка важен не только сам список советов, а форма, в которой он появляется. Когда крупные IT-команды начинают формализовать ошибки начинающих руководителей в виде школы, модулей и вводных уроков, это говорит о взрослении подхода к кадровому резерву. Вопрос теперь не в том, нужны ли компаниям сильные тимлиды, а в том, насколько быстро они научатся выращивать их системно, пока повышение лучшего разработчика по-прежнему остается самым популярным и самым рискованным управленческим экспериментом в отрасли.