Team Lead vs Tech Lead. В чем разница и зачем разделять эти роли
Привет, я Олег Абрамов, VP of Engineering в продуктовой компании iDeals Solutions. Хотел бы поделиться опытом и своими взглядами на особенности управления процессами в IT-компаниях. А именно рассказать подробнее о том, чем отличаются роли Team Lead и Tech Lead и какие функции и задачи могут быть с ними связаны. Прежде всего это будет интересно тем, кто работает в растущих командах или задумывается о карьерном росте на позиции разработчика. А также тем, кого волнуют вопросы эффективного управления в продуктовых компаниях.
Небольшой дисклеймер: подход к этим позициям зачастую отличается в зависимости от размера компании и ее управленческой культуры. В больших организациях спектр задач Team Lead может быть меньше, в небольших — роли тех- и тимлида нередко совмещают. Практика все же показывает, что их лучше разделять. Давайте разберемся почему.
Иллюстрация Алины Самолюк
Кем управляем
Прежде чем говорить непосредственно об управлении, небольшое предисловие о команде. В ней объединяются люди с разными точками зрения, бэкграундом, знаниями и экспертизой. В успешном коллективе возникает синергия: вместе люди понимают и делают больше, чем поодиночке. А значит, результаты в ней растут нелинейно.
В условно «плохой» команде чаще наблюдается линейный рост: общая работа не отличается от суммы индивидуальных результатов. Может быть и хуже — когда люди вообще начинают мешать друг другу. Или же при обсуждении задач члены команды не дополняют и не критикуют (в здравом смысле) решения друг друга. Например, при сложностях у фронтенд-инженера его бэкенд-коллеги уходят в режим «это не мое дело, это „его“ задача, у меня другие проблемы и другие дела».
В такой команде синергия идей никогда не возникнет. Но практика показывает: коллективный разум и анализ часто превосходит индивидуальный, а мастера-одиночки — скорее исключение, чем правило.
Собрать команду из одинаково квалифицированных специалистов едва ли возможно, всегда будет некий дисбаланс знаний. Впрочем, нельзя недооценивать и его пользу. Например, во время брейншторма опытный инженер может счесть некую проблему банальщиной, которую «и так все учтут», тогда как начинающий — задать критически важный вопрос, который поможет избежать серьезных просчетов в дальнейшем.
Например, как-то у нас возник вопрос по поводу скачивания «тяжелых» файлов в разрабатываемом дополнении к нашей системе. Более опытные коллеги предложили два варианта решения инженеру, перед которым стояла эта задача. Он решил исследовать проблему с нуля и увидел недостатки в обоих решениях. Инвестировав дополнительное время, он нашел третий, оптимальный подход. Коллеги его поддержали. В итоге в релизе решение дало существенное ускорение и улучшило пользовательский опыт. Таким образом, порой out of box thinking дает продуктивные результаты — как с точки зрения бизнеса, так и с точки зрения технологий.
Но вернемся к командам. Когда число участников переваливает за
Какие вызовы появляются с масштабированием
Когда в команде три человека — условно [Tech/Team] Lead и пара Middle — скорее всего, сложностей с управлением не возникнет. Здесь лид «и швец, и жнец, и на дуде игрец». На нем и собственноручная разработка решений, и ревью кода других, и управление командой.
Такая структура стабильна и работает хорошо. Единственное, что может ее разрушить — необходимость развития и/или расширение горизонта планирования.
Давайте посмотрим на реальный кейс. Команда Lead’a Алекса занялась сложным проектом, руководство регулярно спрашивает о сроках. Сам он раньше никогда не планировал на среднесрочную перспективу — например, на месяц-два. В итоге Алекс вместо кодинга погружается в оценку и планирование, вместо анализа локальных технических изменений — в учет рисков. Как результат, все меньше кода пишет сам.
На этом, конечно, приключения не заканчиваются. Проект развивается, команда растет. Руководство начинает требовать метрики эффективности каждого инженера. Любящий data-driven подход Алекс принимается изучать показатели, чтобы понять, что и где можно улучшить. Да, он начинает замечать, какие проблемы есть у каждого из инженеров в работе, и пытается им с этим помочь. Но времени на технический контекст и развитие собственной экспертизы остается еще меньше.
Логичный следующий этап — найти в команду инженера с лидерскими качествами, который бы «остался в технологиях». Такой специалист помог бы развивать и поддерживать техническое качество решений команды — Tech Lead. Сам же Алекс, если хорошо справляется с управлением людьми и проектами, становится Team Lead.
То есть вместе с ростом команды возникает необходимость разделить лидерство на «техническое» и «управленческое». Для достижения результатов команде нужны оба «крыла». Первое — чтобы задавать направление движения в сфере технологий и экспертного развития коллег. Второе — для эффективной координации, создания здоровой и продуктивной атмосферы и ориентации на бизнес-цели и результаты.
Кто такой Tech Lead
Если сказать упрощенно, это один из самых опытных специалистов команды, который предпочитает глубоко погружаться в технические задачи, но не решать сложные вопросы управления людьми. Он кайфует от этого и не даст команде совершить серьезные инженерные просчеты.
В разных компаниях нагрузка и функции могут отличаться. Условно занятость Tech Lead можно описать так:
30-40% времени он проводит за написанием кода.30-40% — архитектура, прототипы будущих решений, глубинная проработка технических рисков и проекция их на время (совместно с Team Lead).- Оставшееся время — code review, менторинг и skill-sharing внутри команды.
Второй и третий блоки, собственно, составляют сущность роли техлида, где она начинает сильно отличаться от Senior. Давайте разберем их подробнее. Основная задача техлида — обеспечивать качественную техническую проработку и реализацию продукта. Что именно стоит считать «техническим лидерством»?
- Создание общей технологической канвы команды: архитектура, системный дизайн, технологические best-practices.
- Работа с техническими рисками и проблемами в процессе разработки: поиск, решение, минимизация трудозатрат.
- Профессиональная прокачка команды: от консультирования и менторства до тематических дискуссий среди коллег по техническим вопросам, качественного code review.
Это не просто: нужно не только вести за собой, но и самому оставаться в форме, а значит, постоянно совершенствовать свои знания. Едва ли это возможно без искренней любви к технологиям и соответствующего склада ума. Но в большой команде быть одновременно и классным технарем, и хорошим менеджером сложно: эти роли все же полагаются на разный набор компетенций. И если сильный специалист отдает предпочтение управленческой ветке развития карьеры, стоит посмотреть на роль Team Lead.
Кто такой Team Lead
Эта позиция имеет смысл уже в разросшейся команде — от 5 человек. Здесь управление связано с непрерывной коммуникацией как с разработчиками, так и с коллегами из других команд, с менеджментом ожиданий, ресурсов и изменений. С ростом коллектива транзакционные издержки растут, поэтому взваливать эти функции на техлида или старшего разработчика будет непродуктивно. И в здоровых командах, где следят за эффективностью, появляется Team Lead.
Если сравнить команду разработчиков с кораблем (не «Титаником»), то техлида можно назвать главным механиком, который обеспечивает надежную работу всего судна. Тимлид же в этом случае — капитан: он прокладывает курс и следит за слаженной работой команды и механизмов.
Что может входить в его задачи в продуктовой компании?
- Погружение в бизнес-аспект: ты не можешь поставить задачу, если сам ее не понимаешь.
- Кросс-командная и кросс-функциональная коммуникация: постоянное выравнивание направлений работы и избавление от неопределенности.
- Создание процессов и повышение слаженности работы команды: неструктурированность — главный враг растущих организаций.
- People management — оценка, планирование, распределение задач, проведение one-to-one встреч, решение возникающих конфликтов, мотивация коллег, решение рутинных вопросов с отпусками, отгулами и овертаймами.
- Обратная связь и развитие команды: каждый человек хочет развиваться, даже самый сеньорный сеньор. Именно Team Lead должен поддерживать и давать реализовывать эти стремления.
- Найм, on- и offboarding: Team Lead должен искать и «растить» топовых teammates, помогать им быть эффективными и не бояться расставаться с теми, кто не подходит.
Есть подход, при котором тимлид в инженерной команде — не обязательно инженер, а специалист с развитыми управленческими навыками. Он успешно работает во многих компаниях. Но стоит признать, что не каждый человек без технического бэкграунда может завоевать достаточное доверие команды «технарей», чтобы управлять ими. Тимлид как минимум должен понимать, какие задачи ставит своей команде.
Как мы управляем разработкой в iDeals
В iDeals мы уже прошли этап горизонтальной структуры, когда каждая функция (BE, FE, QA) имела своего Team Lead, и пришли к вертикальным кросс-функциональным командам. Эта тема требует отдельной статьи, поэтому здесь опишу ситуацию вкратце.
Итак, сейчас в каждой команде у нас
Глава этой команды — Engineering Manager. Это человек с опытом в разработке (как правило — Back-end/Full Stack в прошлом), хорошо понимает контекст построения решений end-to-end, но предпочитает вертикальный рост в компании, а не горизонтальный. Фактически он имеющий инженерный бэкграунд Team Lead. Но от этого термина мы решили избавиться, потому что на рынке он имеет разные значения и зачастую создает неправильные ожидания.
Engineering Manager опирается на Seniors/Tech Leads, отвечает за итоговые показатели, процессы разработки и объединение контекстов всех трех функций (FE, BE, QA) в команде для принятия оптимальных решений. Кроме того, people management задачи: у него есть все рычаги для обеспечения лучших результатов работы команды и необходимый уровень автономности.
Такой подход позволяет нашим Engineering Managers и оставаться в поле технологий, и прокачивать управленческие скиллы, чтобы на всех уровнях улучшать процесс создания решений своей командой.
С грамотным развитием специалистов и/или хорошими наймами на эту роль создается правильный профицит управленческой функции. Для быстро растущего продукта (iDeals растет на
Какой результат? В целом техническая и бизнесовая части у нас работают в синергии. Нам удается избегать длительных обсуждений для принятия решений, команды становятся продуктивнее и автономнее.
Подытожим:
- При росте команды разработчиков неизбежно возникает потребность в функциях экспертного руководства и управления людьми.
- Эффективно совмещать «техническое» и «управленческое» лидерство сложно: эти задачи требуют развития разных скиллов и глубокого погружения в различные контексты.
- В идеале, в фокусе техлида — прокладывание технологического курса развития продукта и работы команды, как и повышение профессиональной квалификации коллег.
- Тимлид обеспечивает слаженную и структурированную работу всей Engineering-команды и служит связующим звеном с другими функциями в компании.
- Развитие сотрудников по одной из двух веток, в зависимости от их предпочтений, закладывает фундамент для дальнейшего успешного роста компании.
А как, с вашей точки зрения, должны выглядеть задачи техлида и тимлида? Поделитесь в комментариях!
