Привет, я Олег Абрамов, VP of Engineering в продуктовой компании iDeals Solutions. Хотел бы поделиться опытом и своими взглядами на особенности управления процессами в IT-компаниях. А именно рассказать подробнее о том, чем отличаются роли Team Lead и Tech Lead и какие функции и задачи могут быть с ними связаны. Прежде всего это будет интересно тем, кто работает в растущих командах или задумывается о карьерном росте на позиции разработчика. А также тем, кого волнуют вопросы эффективного управления в продуктовых компаниях.
Небольшой дисклеймер: подход к этим позициям зачастую отличается в зависимости от размера компании и ее управленческой культуры. В больших организациях спектр задач Team Lead может быть меньше, в небольших — роли тех- и тимлида нередко совмещают. Практика все же показывает, что их лучше разделять. Давайте разберемся почему.
Иллюстрация Алины Самолюк
В условно «плохой» команде чаще наблюдается линейный рост: общая работа не отличается от суммы индивидуальных результатов. Может быть и хуже — когда люди вообще начинают мешать друг другу. Или же при обсуждении задач члены команды не дополняют и не критикуют (в здравом смысле) решения друг друга. Например, при сложностях у фронтенд-инженера его бэкенд-коллеги уходят в режим «это не мое дело, это „его“ задача, у меня другие проблемы и другие дела».
В такой команде синергия идей никогда не возникнет. Но практика показывает: коллективный разум и анализ часто превосходит индивидуальный, а мастера-одиночки — скорее исключение, чем правило.
Собрать команду из одинаково квалифицированных специалистов едва ли возможно, всегда будет некий дисбаланс знаний. Впрочем, нельзя недооценивать и его пользу. Например, во время брейншторма опытный инженер может счесть некую проблему банальщиной, которую «и так все учтут», тогда как начинающий — задать критически важный вопрос, который поможет избежать серьезных просчетов в дальнейшем.
Например, как-то у нас возник вопрос по поводу скачивания «тяжелых» файлов в разрабатываемом дополнении к нашей системе. Более опытные коллеги предложили два варианта решения инженеру, перед которым стояла эта задача. Он решил исследовать проблему с нуля и увидел недостатки в обоих решениях. Инвестировав дополнительное время, он нашел третий, оптимальный подход. Коллеги его поддержали. В итоге в релизе решение дало существенное ускорение и улучшило пользовательский опыт. Таким образом, порой out of box thinking дает продуктивные результаты — как с точки зрения бизнеса, так и с точки зрения технологий.
Но вернемся к командам. Когда число участников переваливает за 5-7 человек, возникают вопросы: кто должен обучать и направлять (управлять экспертизой), а кто — организовывать эффективную работу (управлять командой).
Такая структура стабильна и работает хорошо. Единственное, что может ее разрушить — необходимость развития и/или расширение горизонта планирования.
Давайте посмотрим на реальный кейс. Команда Lead’a Алекса занялась сложным проектом, руководство регулярно спрашивает о сроках. Сам он раньше никогда не планировал на среднесрочную перспективу — например, на месяц-два. В итоге Алекс вместо кодинга погружается в оценку и планирование, вместо анализа локальных технических изменений — в учет рисков. Как результат, все меньше кода пишет сам.
На этом, конечно, приключения не заканчиваются. Проект развивается, команда растет. Руководство начинает требовать метрики эффективности каждого инженера. Любящий data-driven подход Алекс принимается изучать показатели, чтобы понять, что и где можно улучшить. Да, он начинает замечать, какие проблемы есть у каждого из инженеров в работе, и пытается им с этим помочь. Но времени на технический контекст и развитие собственной экспертизы остается еще меньше.
Логичный следующий этап — найти в команду инженера с лидерскими качествами, который бы «остался в технологиях». Такой специалист помог бы развивать и поддерживать техническое качество решений команды — Tech Lead. Сам же Алекс, если хорошо справляется с управлением людьми и проектами, становится Team Lead.
То есть вместе с ростом команды возникает необходимость разделить лидерство на «техническое» и «управленческое». Для достижения результатов команде нужны оба «крыла». Первое — чтобы задавать направление движения в сфере технологий и экспертного развития коллег. Второе — для эффективной координации, создания здоровой и продуктивной атмосферы и ориентации на бизнес-цели и результаты.
В разных компаниях нагрузка и функции могут отличаться. Условно занятость Tech 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% в год) это суперважно.
Какой результат? В целом техническая и бизнесовая части у нас работают в синергии. Нам удается избегать длительных обсуждений для принятия решений, команды становятся продуктивнее и автономнее.
Подытожим:
dou.ua
Небольшой дисклеймер: подход к этим позициям зачастую отличается в зависимости от размера компании и ее управленческой культуры. В больших организациях спектр задач 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 внутри команды.
- Создание общей технологической канвы команды: архитектура, системный дизайн, технологические best-practices.
- Работа с техническими рисками и проблемами в процессе разработки: поиск, решение, минимизация трудозатрат.
- Профессиональная прокачка команды: от консультирования и менторства до тематических дискуссий среди коллег по техническим вопросам, качественного code review.
Кто такой 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-команды и служит связующим звеном с другими функциями в компании.
- Развитие сотрудников по одной из двух веток, в зависимости от их предпочтений, закладывает фундамент для дальнейшего успешного роста компании.
DOU
DOU – Найбільша спільнота розробників України. Все про IT: цікаві статті, інтервʼю, розслідування, дослідження ринку, свіжі новини та події. Спілкування на форумі з айтівцями на найгарячіші теми та технічні матеріали від експертів. Вакансії, рейтинг IT-компаній, відгуки співробітників, аналітика...
dou.ua