Прийшов час осідлати справжнього Буцефала🏇🏻Приборкай норовливого коня разом з Newxel🏇🏻Умови на сайті
×Закрыть

Team Lead vs Tech Lead. В чем разница и зачем разделять эти роли

Привет, я Олег Абрамов, VP of Engineering в продуктовой компании iDeals Solutions. Хотел бы поделиться опытом и своими взглядами на особенности управления процессами в IT-компаниях. А именно рассказать подробнее о том, чем отличаются роли Team Lead и Tech Lead и какие функции и задачи могут быть с ними связаны. Прежде всего это будет интересно тем, кто работает в растущих командах или задумывается о карьерном росте на позиции разработчика. А также тем, кого волнуют вопросы эффективного управления в продуктовых компаниях.

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

Иллюстрация Алины Самолюк

Кем управляем

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

В условно «плохой» команде чаще наблюдается линейный рост: общая работа не отличается от суммы индивидуальных результатов. Может быть и хуже — когда люди вообще начинают мешать друг другу. Или же при обсуждении задач члены команды не дополняют и не критикуют (в здравом смысле) решения друг друга. Например, при сложностях у фронтенд-инженера его бэкенд-коллеги уходят в режим «это не мое дело, это „его“ задача, у меня другие проблемы и другие дела».

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

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

Например, как-то у нас возник вопрос по поводу скачивания «тяжелых» файлов в разрабатываемом дополнении к нашей системе. Более опытные коллеги предложили два варианта решения инженеру, перед которым стояла эта задача. Он решил исследовать проблему с нуля и увидел недостатки в обоих решениях. Инвестировав дополнительное время, он нашел третий, оптимальный подход. Коллеги его поддержали. В итоге в релизе решение дало существенное ускорение и улучшило пользовательский опыт. Таким образом, порой out of box thinking дает продуктивные результаты — как с точки зрения бизнеса, так и с точки зрения технологий.

Но вернемся к командам. Когда число участников переваливает за 5-7 человек, возникают вопросы: кто должен обучать и направлять (управлять экспертизой), а кто — организовывать эффективную работу (управлять командой).

Какие вызовы появляются с масштабированием

Когда в команде три человека — условно [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, и пришли к вертикальным кросс-функциональным командам. Эта тема требует отдельной статьи, поэтому здесь опишу ситуацию вкратце.

Итак, сейчас в каждой команде у нас 2-3 Back-end Engineers, 1-2 Front-end Engineers, 2-3 QA/AQA Engineers. В среднем — 7-8 человек. Как правило, команда состоит из Senior/Middle+ специалистов, которые достаточно автономны (70-90% решений принимается самостоятельно).

Глава этой команды — Engineering Manager. Это человек с опытом в разработке (как правило — Back-end/Full Stack в прошлом), хорошо понимает контекст построения решений end-to-end, но предпочитает вертикальный рост в компании, а не горизонтальный. Фактически он имеющий инженерный бэкграунд Team Lead. Но от этого термина мы решили избавиться, потому что на рынке он имеет разные значения и зачастую создает неправильные ожидания.

Engineering Manager опирается на Seniors/Tech Leads, отвечает за итоговые показатели, процессы разработки и объединение контекстов всех трех функций (FE, BE, QA) в команде для принятия оптимальных решений. Кроме того, people management задачи: у него есть все рычаги для обеспечения лучших результатов работы команды и необходимый уровень автономности.

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

С грамотным развитием специалистов и/или хорошими наймами на эту роль создается правильный профицит управленческой функции. Для быстро растущего продукта (iDeals растет на 20-30% в год) это суперважно.

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


Подытожим:

  • При росте команды разработчиков неизбежно возникает потребность в функциях экспертного руководства и управления людьми.
  • Эффективно совмещать «техническое» и «управленческое» лидерство сложно: эти задачи требуют развития разных скиллов и глубокого погружения в различные контексты.
  • В идеале, в фокусе техлида — прокладывание технологического курса развития продукта и работы команды, как и повышение профессиональной квалификации коллег.
  • Тимлид обеспечивает слаженную и структурированную работу всей Engineering-команды и служит связующим звеном с другими функциями в компании.
  • Развитие сотрудников по одной из двух веток, в зависимости от их предпочтений, закладывает фундамент для дальнейшего успешного роста компании.

А как, с вашей точки зрения, должны выглядеть задачи техлида и тимлида? Поделитесь в комментариях!

LinkedIn

Похожие статьи

17 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Узагалі, якщо чесно, в аутстафi і аутсорсi в 90% випадків немає ні того, ні іншого. Якщо ми говоримо про українські команди. Всі ці завдання, які ви описали, виконують люди на тій стороні.

Не зовсім зрозумів, чим у вашій посадовій ієрархії Team Lead відрізняється від тієї ролі, яку відіграє PM?

Дякую за чудову, гарно структурована статтю!
Розставити крапки над і. А то деколи здається чому нехватає часу на кодінг, чому стільки «управлінських/організаційних» справ, а все можливо через те, що хтось почав виконувати обов’язки тім ліда.

Имхо, статью надо было бы назвать «Как у нас настроены процессы». Потому что данные роли и их обязаности очень сильно разнятся от компаниии к компании. Я, например, никогда не встречал такую ситуацию, что был и тех и тим лид. Обычно, people management был на скрам мастере, или инжиниринг менеджере. Требования бизнеса — на ПО и тех лиде. И то, это только в моем случае, я уверен, что найдутся люди, которые опишут диаметрально противоположное.
Да, оно так может работать в отдельной компании, но я бы не воспринимал это как чистую монету

Да, Алексей, как и написал в статье, понимание и подход к этому вопросу у каждой компании свой. Важнее, скорее, разобраться в разведении «человеческой-управленческой» и «технологической» функций.
Идеальной модели, само собой, нет — в разных командах и бизнесах работают свои подходы. Но, как вы сами правильно отмечаете, people/project management функции и бизнес-вопросы в командах разработчиков может решать как один специалист (например, в продуктовой компании), так и разные (что нередко встречается в аутсорсе).
И это важная задача менеджмента — понять, какой подход покажет бОльшую эффективность.

30-40% — архитектура, прототипы будущих решений, глубинная проработка технических рисков и проекция их на время (совместно с Team Lead).

це задачі архітектора, а не тех-ліда. Так само, як і код рев’ю і шерінг знань — задачі всіх (!) членів команди.

це задачі архітектора, а не тех-ліда

В разных компаниях позиции архитектора и лида очень сильно плавают по обязанностям. Например, Solution Architect часто собственно маппингом домена на тех часть детально не занимается, а даёт только хай-левел архитектуру, оставляя тех лидам тот же дизайн баз, что вполне себе архитектурная задача. При чём

глубинная проработка технических рисков

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

глубинная проработка технических рисков и проекция их на время

це не про техдебт — це про масштабування і гнучкість системи в майбутньому. В масштабі системи\епіка — це задача архітектора. В масштабах конкретної юзер сторі\таски — це задача сторі овнера\дева. Я не розумію, яке відношення тех.дебт (читаємо — палкі та синя ізолента) мають до цього? Якщо, у нас, костилі мають вплив на архітектуру значить у лідів щось давно пішло не так.
P.S. На рахунок першої половини Вашого комента — згідний на 100%.

Якщо, у нас, костилі мають вплив на архітектуру значить у лідів щось давно пішло не так.

А в проектах часто что-то идёт не так, особенно из-за сроков и неопределённости требований — иначе любой проект с архитектором становился бы технически успешным автоматически). К сожалению, синяя изолента иногда вылазит за пределы даже одного сервиса в SOA, и это непосредственным образом начинает влиять на гибкость и масштабируемость всей системы.

Честно говоря, роли архитектора тоже очень сильно разнятся. Есть Systems, Applications/Software, Solutions и Enterprise. Вы о каком говорите? :)

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

Я поддержу комментарии Максима. По-моему, ни один Software Architect не может самостоятельно строить как глобальный, так и локальный технические оптимумы в большом продукте. Это трудно, если не невозможно — и такой архитектор очень быстро превратится в Ivory Tower Architect, который оторван от реальности.

Поэтому локальный технический оптимум скорее уходит на Tech Lead, глобальный — формируется Software Architect в тесной кооперации и синхронизации с несколькими Tech Leads.
Как я и писал в статье — коллективный разум с четким алгоритмом согласования превосходит мастеров-одиночек. И кооперация Tech Lead и Software Architect — один из таких примеров.

Понравилось сравнение ролей на примере корабля. В некоторых компаниях роль «капитана» может выполнять проджект менеджер.

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

У семи лидов пуллреквест замержен с багою

Дякую за цікаву статтю. Якраз на роздоріжжі Team/Tech leading.

Від себе також порекомендую www.youtube.com/watch?v=65zn96QkYLk

Дякую за статтю. Маю питання, як вирішують конфлікти ваші ЕМ (Engineering Manager) і що на вашу думку є важкою задачою в управлінні людьми для EM?

Романе, дякую, дуже слушне запитання. Ідеальна ситуація для Engineering Manager — робота з тим, щоб конфлікти, принаймні гострі, не виникали. Для цього потрібно як вибудовувати довіру в команді, так і вміти побачити потенційні зони ризику. У разі конфлікту членів команди варто виступати третьою стороною, медіатором, який допоможе людям порозумітися.

Із цим пов’язаний чи не найбільший виклик для EM: потрібні прокачані комунікаційні навички та глибоке занурення у контекст (у тому числі — технічний, якщо він є причиною конфлікту).
З іншого боку, в iDeals ми покладаємося ще й на внутрішню зрілість людей і їхню орієнтацію на ефективну співпрацю та готовність прямо говорить про складнощі, не чекаючи, доки вони набудуть серйозного характеру.

Подписаться на комментарии