Кто такой tech lead
Team Lead vs Tech Lead: кто есть кто
Представляем статью Олега Абрамова, VP of Engineering в iDeals Solutions, вышедшую на DOU.UA. Из этой статьи вы узнаете, чем отличается тимлид от техлида и чем занимаются люди на этих позициях.
Привет, я Олег Абрамов, 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 можно описать так:
Второй и третий блоки, собственно, составляют сущность роли техлида, где она начинает сильно отличаться от Senior. Давайте разберем их подробнее. Основная задача техлида — обеспечивать качественную техническую проработку и реализацию продукта. Что именно стоит считать «техническим лидерством»?
Это не просто: нужно не только вести за собой, но и самому оставаться в форме, а значит, постоянно совершенствовать свои знания. Едва ли это возможно без искренней любви к технологиям и соответствующего склада ума. Но в большой команде быть одновременно и классным технарем, и хорошим менеджером сложно: эти роли все же полагаются на разный набор компетенций. И если сильный специалист отдает предпочтение управленческой ветке развития карьеры, стоит посмотреть на роль Team Lead.
Кто такой Team Lead
Эта позиция имеет смысл уже в разросшейся команде — от 5 человек. Здесь управление связано с непрерывной коммуникацией как с разработчиками, так и с коллегами из других команд, с менеджментом ожиданий, ресурсов и изменений. С ростом коллектива транзакционные издержки растут, поэтому взваливать эти функции на техлида или старшего разработчика будет непродуктивно. И в здоровых командах, где следят за эффективностью, появляется Team Lead.
Если сравнить команду разработчиков с кораблем (не «Титаником»), то техлида можно назвать главным механиком, который обеспечивает надежную работу всего судна. Тимлид же в этом случае — капитан: он прокладывает курс и следит за слаженной работой команды и механизмов.
Что может входить в его задачи в продуктовой компании?
Есть подход, при котором тимлид в инженерной команде — не обязательно инженер, а специалист с развитыми управленческими навыками. Он успешно работает во многих компаниях. Но стоит признать, что не каждый человек без технического бэкграунда может завоевать достаточное доверие команды «технарей», чтобы управлять ими. Тимлид как минимум должен понимать, какие задачи ставит своей команде.
Как мы управляем разработкой в 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% в год) это суперважно.
Какой результат? В целом техническая и бизнесовая части у нас работают в синергии. Нам удается избегать длительных обсуждений для принятия решений, команды становятся продуктивнее и автономнее.
Без тимлида не обойтись, а что насчет техлида?
Меня зовут Ваня Антипин, я Deputy CTO в компании AGIMA. Сегодня я постараюсь вам рассказать про роль техлида в компании. Напомню, что в октябре 2020 года мы говорили о роли тимлида в компании и команде. Если кратко — от тимлида зависит многое, включая эффективность команды, достижение поставленных целей, оперативное решение рабочих тасков.
А что насчет техлида? Об этой специальности говорят не так часто, но техлиды важны и нужны не менее тимлидов. Более подробно я рассказываю об этом на курсе «Руководитель команды разработки» и делюсь реальными кейсами. Но не будем отвлекаться, приступим!
Техлид — не специальность, а роль
Главное, что нужно знать о техлиде — то, что это роль. Она может быть формальной, и может быть и номинальной, все зависит от проекта и команды. Так, техлидом может стать и чаще всего становится опытный инженер, который не только оперативно справляется с собственными задачами, но и может помочь коллегам, беря на себя дополнительные технические задачи и ответственность за них.
Что касается формальной или номинальной роли, то в классическом Scrum, например, нет роли техлида, а вот в проектах и командах, которые «живут по Scrum», техлид есть.
Когда нужен техлид? В целом, он будет полезен практически везде и всегда, но особенно важна эта роль на больших проектах, где много задач, насыщенная архитектура и команда состоит из 3-х и более человек.
А что насчет обязанностей?
Основная задача техлида — техническое ведение проекта, включая как всю целиком архитектуру решений, так и какие-то отдельные части. Техлид — эксперт по технологиям реализуемого компанией проекта. За ним обычно — последнее слово в принятии технических решений.
Пример — разработка мобильного приложения. Если проект большой, то здесь обязанности техлида и тимлида редко пересекаются. Так, техлид отвечает за архитектуру мобильных приложений под две платформы, iOS и Android, за проектирования REST API в контексте разрабатываемой мобильной архитектуры. А вот за управление проектом, разработку серверной реализации API и результаты всего проекта отвечает тимлид.
Если проект не очень большой, то случается, что тимлид забирает на себя задачи техлида — это те самые Hard-скиллс, которые нужны тимлиду наравне с Soft-скиллс.
Кстати, одна из главных задач техлида — процесс управления техническим долгом проекта. Технический долг — это несделанная в проекте работа, которая будет мешать его развитию в будущем, если так и не будет выполнена. В технический долг не включаются баги или отложенные низкоприоритетные фичи. Технический долг — это, например, плохо спроектированная архитектура или запутанный код. Управление техническим долгом — это его постоянный поиск, подсчёт стоимости и постепенное устранение.
Техлиды и тимлиды – зоны ответственности
Мы сразу провели границу между тимлидами и техлидами. Техлид — это упор на Hard-скиллс, а тимлид — на Soft-скиллс. Граница — в соотношении этих навыков, причем в зависимости от контекста, заданного проектом и командой.
Для того чтобы прояснить ситуацию, приведу пример. Это кросс-платформенные проекты с сервис-ориентированной архитектурой по разработке омниканальных цифровых витрин. В рамках такого проекта разрабатываются web&mobile-приложения, сервисы управления контентом, сервисы интеграции и реализации бизнес-логики (API). В таком проекте может быть целая команда лидов:
Тимлид, управляющий процессами, коммуникациями и бюджетом.
Техлиды для каждой платформы, отвечающие за технические аспекты архитектуры и реализацию решений.
Разберемся детальнее с распределением ответственности между тимлидом и техлидом на примере процесса управления разработкой в контексты реализации фичей из бэклога. Процесс может быть таким:
Списком задач в бэклоге управляет руководитель проекта. Задачи по разработке уходят в работу на тимлида.
Тимлид получает задачу, проверяет точность и полноту требований в задаче, при необходимости уточняет детали или дополняет описание задачи описанием уточнением требований или описанием возможной реализации. Задача уходит в работу на техлида. При этом на проекте работает три техлида: фронт, бэк, мобилка; – и тимлид понимает из описания, на кого делегировать задачу.
Техлид получает задачу, проверяет точность и полноту требований в задаче, при необходимости дополняет описание задачи своей экспертизой в предметной области, может описать реализацию или уточнить по реализации предложенной тимлидом.
Техлид определяет исполнителя и отдаёт задачу в работу.
Задача от разработчика возвращается на код-ревью к техлиду и техлид принимает задачу или отправляет на доработку с комментарием содержащим уточнения и рекомендации.
В таком процессе за техническое качество реализации отвечает техлид, а тимлид — за сроки и бюджет.
В целом, тимлиду обязательно нужны технические знания, но они могут быть не настолько глубокими, как у техлида. А вот техлид в обязательном порядке должен быть экспертом во всех технологиях, которые используются в проекте, за который он отвечает.
Знания, умения и скиллы – поговорим конкретнее
Важный момент в понимании сути работы техлида состоит в том, что техлид это эксперт. В то же время далеко не каждый эксперт — техлид. Выше мы говорили, что техлид — это, в основном, про Hard-скиллы. Но он должен владеть и определенным набором Soft-скиллов, ведь ему тоже нужно коммуницировать внутри команды, а также управлять знаниями о технологиях.
Базовый набор Soft-скиллс:
Поиск и подбор кандидата, собеседование.
Постановка личных целей.
Стратегическое видение развития.
Отношения с людьми: эмпатия и эмоциональный интеллект.
Базовый набор Hard-скиллс:
Знание языков разработки и опыт программирования. Знание сопутствующих и окружающих этот стек технологий.
Понимание архитектуры проекта: принципы проектирования архитектуры, паттерны и инструменты.
Процессы и инструменты тестирования. Оптимизация тестирования, метрики и мониторинг.
Теперь стоит поговорить о технологиях и инструментах, которыми должен владеть хороший техлид. Его зона ответственности — технологии, IT-ландшафт проекта и технологический стек, реализующий бизнес-логику в контексте проекта. Соответственно, технологий много, а их сочетаний — еще больше, причем для каждого конкретного проекта это сочетание уникально. Поэтому имеет смысл говорить не о конкретных программах, а сразу о классах решений и инструментов:
Текстовые редакторы и интегрированные среды разработки.
Инструменты для создания схем в разных графических нотациях и офисные программы.
Системы управления задачами и проектом.
Системы управления знаниями и документаций.
Системы управления версиями кода и инструменты CI/CD.
Системы контейнеризации и инструменты DevOps.
Системы мониторинга и управления инцидентами.
Серверные операционные системы и их сервисы.
Скрипты и собственные наработки кода.
Кто может стать техлидом?
В целом, любой опытный разработчик, который любит и умеет глубоко погружаться в технологии, плюс эффективно управляет собственными знаниями и ориентируется на вертикальное масштабирование компетенций. Время, которое нужно для того, чтобы стать хорошим техлидом, определить сложно. Здесь высокая корреляция между проектами и профессионализмом. В целом, техлид становится техлидом примерно за год работы в проекте, насыщенном технологиями.
Те же из разработчиков, кто эффективно работает и с базовыми знаниями по разным технологиям, плюс ориентируется на горизонтальное масштабирование, могут быть очень хорошими разработчиками-инженерами, тимлидами, при условии наличия соответствующих амбиций и софт-скиллов. Но вот техлидами они вряд ли станут.
Для становления в качестве профессионала нужно быть очень сильно увлеченным технологиями человеком, который при этом владеет навыками самоорганизации. Не помешает еще и умение мыслить стратегически, плюс уметь видеть перспективность тех либо иных технологий в применении к текущему проекту.
Кто такой техлид и как с ним обращаться
Всем привет! Сегодня в гостях у нас Олег Мельник — Technical Lead в компании Proxify, а также преподаватель в OTUS.
Поговорили с Олегом про такую роль у разработчиков как техлид.
— Кто такой техлид и как с ним обращаться?
Технический лидер — это, по сути, умный инженер, который завоевал авторитет в команде своими свежими идеями, инициативностью и высокой деятельностью, и стал неформальным лидером этой группы. Такой инженер-технический лидер обычно отстаивает новаторские позиции и делает это весьма убедительно и харизматично. Нюанс в том, что если ты уж стал техлидом, то, вероятно, обратно превратиться в простого инженера уже не сможешь.
Важно понимать, что появление такого инициативного человека в команде может так же быстро и погаснуть, если не развивать и не подкреплять эту инициативность поощрением, вниманием и похвалами. Однако не стоит питать иллюзий, что будто-бы нужно часто хвалить технического лидера. Нет, отнюдь, хвалить нужно только за выполненную работу, а не за пустые идеи, иначе техлид может зазнаться, и его легко будет потерять вовсе.
Отметим, что, войдя в привычный обиход, термин “технически лидер” станет вскоре официальной должностью в России. Ведь, согласитесь, команда существенно страдает за неимением такого неформального лидера, который, к тому, же обладает в достаточной степени профессиональными техническими навыками и знаниями.
— В чем состоит работа технического лидера?
Все зависит от вида бизнеса, но есть кое-что, что возлагается на самого техлида исключительным образом. Но есть ряд задач, которые являются универсальными для этого человека:
Подбирает технологию или набор технологий для определенных рабочих задач Может ли команда обойтись без техлида?
Отвечает за инновации и внедрение новейших методик к созданию ПО, тестингу, доставке и разработке технологических решений в компании
Занимается практической инженерией, отлаживает бизнес-процессы, такие как CI/CD и прочие
Устраняет технические неполадки и контролирует бизнес-процессы в целом с технической стороны, сводя риски для компании к минимуму
Прописывает стратегию в области технологий для компании и работает на развитие бизнеса
Берет на себя ответственность за техническую реализацию продукта компании
Помогает своей команде приобрести минимальные технические навыки для более эффективной работы в компании
Разрешает более сложные задания с технической стороны, которые иным инженерам зачастую разрешить не под силу
Чтобы решать данные задачи, техлиду нужно владеть своей профессией в совершенстве, при этом будучи мотиватором для остальных членов команды, чтобы команда могла и сама в какой-то момент заменить технического лидера, если вдруг, что случится нестандартное.
Таким образом, то что делает технический лидер, добавляет весу команде в целом. Его новаторские идеи и решения сокращают временные затраты на производство, тестинг новых продуктов компании. А команда начинает больше технически соображать, меньше допускать типичных ошибок, работать быстрее и эффективнее, и более слаженно.
Тимлид должен переживать за то, чтобы все технические решения были адекватно применимы в компании по отношению к реализации долгосрочных целей, а не только лишь для того, чтобы добиться кратковременного успеха в одном направлении дела.
Ведь долгосрочные цели достигаются только в том случае, если есть ранее ответственное лицо за конечный результат работы. Если такого же нет, то нельзя уверить себя в том, насколько качественный продукт предоставляет компания, ведь если продукт сам по себе качественный, то почему никто не хочет им заняться и двигать к прогрессу?
Более того, грамотный технический лидер может не только заработать компании пару-тройку лишних миллионов долларов, но может также эти миллионы бизнесу сохранить, если предоставит оптимальное техническое решение, которое позволит автоматизировать, усовершенствовать и/или сократить затраты на производственный процесс.
— Какими качествами должен обладать техлид?
Иногда и джуниоры могут становится техлидами, если они обладают соответствующими техническими навыками и лидерскими качества, а также пользуются авторитетом в команде компании.
В глобальном смысле же техлид должен владеть теми навыками и профессионально-личностными данными, о которых мы расскажем вам на Tech Lead Conf в виде развернутой карты усиления компетенций технического лидера, куда входят такие как:
Умение замечать проблемы и нюансы в том, что требует совершенствования, а именно — в повседневной работе команды
Понимание процессов бизнеса и механизма принятия решения, решительность и ответственность по отношению к принятию таких решений
Системные мышление и умение быстро сориентироваться на месте в неопределенных условиях работы
Обоснование, ясное и четкое, своих идей, целей, донесение до коллектива своего мнения и решения, а также пояснение, почему данное решение или мнение будет уместно и должно быть принято во внимание руководством
Обладание лидерскими качествами, умением слушать, вести за собой, обучать команду; использование своего харизматического влияния и авторитета на благо команде и компании
Умение прислушиваться к мнению команды и договариваться с ней даже в особо конфликтных и напряженных рабочих условиях; в то же время техлид должен уметь отстоять собственное мнение и позицию при необходимости, не идя на компромисс, если это вредно для команды и/или компании
Навык быстрого изучения новой области знаний, а также практическое применение и прогнозирование действия любого технического решения, принятого внутри компании, с возможностью и способностью пояснить его не только в коллективе, но и в медийном пространстве.
Обладание эрудицией и обширным кругозором, вовлеченность в медийный процесс, регулярное не безучастное отслеживание технических трендов в своей сфере.
— Зачем техническому лидеру “ручная” работа?
Если техлид перестает работать руками — он деградирует как специалист и теряет авторитет в глазах команды мгновенно. Если технический лидер является также опытнейшим инженером и умнейшим человеком в команде, он может быть своего рода тренером, который всегда играет. Что это означает? Такой техлид обучает других, при этом обучаясь самому. Более того, он не просто обучает, а делает это на собственном примере, что является наиболее надежной и доверительной учебной практикой.
Техлиду не обязательно все время заниматься разработкой, а то у него так времени не хватит на другие задачи, связанные с тем списком, который мы указали выше. Часто техлид может просто выполнять роль ментора, и этого будет достаточно, чтобы команда эффективно работала. Иногда технический лидер работает с кем-то сообща, вроде как в партнерстве в open-source или экспериментирует в pet-project. И это допустимо, главное, чтобы рабочие задачи были выполнены на 100%.
— Может ли команда обойтись без техлида?
Конечно, но бизнес-процессы со временем придут в упадок. Потому что, несмотря на укоренившиеся устои в компании, время не стоит на месте, технологии и методы меняются, и задача технического лидера менять курс своей команды по ветру, то есть следовать за инновациями в ногу со временем.
И тут очень важен человек, который будет за всем этим стоять. Более того, опасно, когда роль технического лидера достается человеку, совершенно ей не соответствующему. Тогда все значительно хуже, ведь компания не просто будет стагнировать, а пойдет по совершенно неверному курсу. А это всегда хуже. Так что позаботьтесь, чтобы в вашем бизнесе обязательно был техлид и чтобы он обязательно, в первую очередь, соответствовал занимаемой им должности.
На старте нового продукта компании очень важно участие технического лидера.
Далее он начинает следить за техническими характеристиками при развитии продукта и управляет рисками, если что пойдет не так. Конечно, несет ответственность за баги и за бюджеты, которые на них сливает. А еще его задачей является не превратить в конечном итоге продукт в то, что потом никто не купит.
Роль команды тут, конечно, тоже важна, но технический лидер управляет процессом с технической стороны и от него все же зависит будущее продукта как технологического решения.
Так что в команде компании может быть еще и не один технический лидер, главное, чтобы от них всех был прок бизнесу. Конечно, все зависит от масштабности проекта и размеров компании. В идеале в малой команде нужен один техлид, а для больших хотя бы два-три, но не более пяти, чтобы не получилось несколько петухов в курятнике.
Если мы говорим о стартапе, то технические лидеры могут совершенно свободно манипулировать информацией, делиться личными компетенциями, предлагать самые смелые решения, даже ссориться в конструктивном смысле пока не найдут тут линию работу, которая ведет бизнес к процветанию. И это нормально. Важно, чтобы когда курс был определен, все успокоились и навалились на него одними усилиями, а не распыляли их на собственные индивидуальности.
— Почему именно техлид?
Да, его задания может выполнить и senior-инженер, но не всегда на 100% корректно. Однако работа и навыки Senior отличаются от работы и навыков технического лидера, и сейчас вы узнаете, почему.