Варианты старта: тимлид в новой или существующей команде

Продолжаем серию постов о переходе из роли старшего инженера в трек начинающего технического менеджера — тимлида.

Как это случается

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

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

Тимлиды вырастают из инженеров разных функций — например, из бэкенда, фронтенда, мобильной разработки или QA. Но старт определяет не столько специализация, сколько то, как человек входит в роль и с какой командой ему предстоит работать.

Стартовые позиции

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

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

Тимлид в новой команде

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

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

Тимлид в существующей команде

Второй сценарий — приход на замену прежнему руководителю (например, после его повышения или ухода). Чистого листа здесь нет: новому тимлиду достаются незакрытые «хвосты», настрой команды, уровень развития людей, процессы и метрики. Всё это нужно быстро оценить.

Ключевой показатель — зрелость команды или Team Maturity Model (TMM): развитая, базового уровня или незрелая. С развитой можно работать на длинную дистанцию, с незрелой — сначала закрывать базовые пробелы.

Акцент смещается на быстрые победы, укрепляющие доверие, и «north stars» для долгосрочного развития.

Сложности вступления в роль

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

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

Онбординг тимлида длится около полугода. За это время необходимо: 

• показать профессиональный авторитет; 

• сделать прозрачными границы роли; 

• быстро погрузиться в боли команды и продукта; 

• обеспечить быстрые победы и план работы со сложными проблемами; 

• системно развивать все три направления: метрики, процессы и людей.

Выводы

Оба сценария имеют свои особенности, но логика старта одна: быстро погрузиться в информационное поле команды, понять её проблематику и в первые одну-две недели выработать краткосрочный план, а ко второму месяцу — долгосрочное видение, ту самую «полярную звезду» развития команды.

Что дальше?

В следующей статье поговорим о целеполагании и планировании: как планировать, когда всё горит и ничего не понятно.

Теперь ты тимлид: роль, майндсет и границы ответственности

Сегодня мы начинаем серию постов о переходе из роли старшего инженера в трек начинающего технического менеджера — тимлида.

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

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

Три направления работы тимлида

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

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

Третье направление — команда. Оно включает активности по определению структуры и компетенций команды, развитию зрелости и лояльности, а также росту и развитию инженеров в зависимости от потребностей продукта и стейкхолдеров.

Границы ответственности и принятие решений

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

Широкая зона ответственности предполагает обширную коммуникацию с различными функциями. Можно выделить следующие крупные точки взаимодействия: 

• discovery составляющая — продакт-оунер, дизайнер, аналитик, редакторы и т. д.;

• техническое руководство — руководители разработки и функциональные руководители направлений; 

• delivery-составляющая — инженеры команды различных функциональных направлений;

• смежники: соседние команды, партнеры, HR-функция, административный персонал и т.д.

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

От теории к практический кейсам

В следующих статьях мы рассмотрим наиболее распространённые ситуационные кейсы:

• Варианты старта: тимлид в новой команде или в существующей.

• Целеполагание: как планировать, когда всё горит и ничего непонятно.

• Команда и люди: офферы, лоу-перформинг, увольнение, друзья, лояльность.

• Процессы: «и так нормально», бюрократия, эксперименты.

• Менеджерские кейсы: приоритеты, риски, разделение команд.

• Сложные ситуации: конфликты, смена продукта, откат обратно в инженеры, микроменеджмент.

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