Содержание
В идеале, в фокусе техлида — прокладывание технологического курса развития продукта и работы команды, как и повышение профессиональной квалификации коллег. Например, как-то у нас возник вопрос по поводу скачивания «тяжелых» файлов в разрабатываемом дополнении к нашей системе. Более опытные коллеги предложили https://deveducation.com/ два варианта решения инженеру, перед которым стояла эта задача. Он решил исследовать проблему с нуля и увидел недостатки в обоих решениях. Инвестировав дополнительное время, он нашел третий, оптимальный подход. В итоге в релизе решение дало существенное ускорение и улучшило пользовательский опыт.
- В iDeals мы уже прошли этап горизонтальной структуры, когда каждая функция имела своего Team Lead, и пришли к вертикальным кросс-функциональным командам.
- Для достижения результатов команде нужны оба «крыла».
- И в здоровых командах, где следят за эффективностью, появляется Team Lead.
- Руководство начинает требовать метрики эффективности каждого инженера.
- И это важная задача менеджмента — понять, какой подход покажет бОльшую эффективность.
- На нем и собственноручная разработка решений, и ревью кода других, и управление командой.
Но от этого термина мы решили избавиться, потому что на рынке он имеет разные значения и зачастую создает неправильные ожидания. Руководство начинает требовать метрики эффективности каждого инженера. Любящий data-driven подход Алекс принимается изучать показатели, чтобы понять, что и где можно улучшить. Да, он начинает замечать, какие проблемы есть у каждого из инженеров в работе, и пытается им с этим помочь. Но времени на технический контекст и развитие собственной экспертизы остается еще меньше.
Кто такой Team Lead
Как правило, команда состоит из Senior/Middle+ специалистов, которые достаточно автономны (70-90% решений принимается самостоятельно). Имхо, статью надо было бы назвать «Как у нас настроены процессы». Потому что данные роли и их обязаности очень сильно разнятся от компаниии к компании. Я, например, никогда не встречал такую ситуацию, что был и тех и тим лид. Обычно, people management был на скрам мастере, или инжиниринг менеджере. И то, это только в моем случае, я уверен, что найдутся люди, которые опишут диаметрально противоположное.
Когда в команде три человека — условно [Tech/Team] Lead и пара Middle — скорее всего, сложностей с управлением не возникнет. На нем и собственноручная разработка решений, и ревью кода других, и управление командой. Эти роли решают совершенно разные задачи, и некоторые из них выходят далеко за рамки построения софта прикладного уровня.
Как мы управляем разработкой в iDeals
Хотел бы поделиться опытом и своими взглядами на особенности управления процессами в IT-компаниях. А именно рассказать подробнее о том, чем отличаются роли Team Lead и Tech Lead и какие функции и задачи могут быть с ними связаны. Прежде всего это будет интересно тем, кто работает в растущих командах или задумывается о карьерном росте на позиции разработчика. А также тем, кого волнуют вопросы эффективного управления в продуктовых компаниях. Идеальной модели, само собой, нет — в разных командах и бизнесах работают свои подходы. Фактически он имеющий инженерный бэкграунд Team Lead.
Является по сути балансировкой уровня тех долга, что по дефолту — не задача архитектора. Т.е., на первых порах тех лид может решить сделать костыль по разным причинам, team lead vs tech lead а через определённое время запедалить уже, как задумывалось. Единственное, что может ее разрушить — необходимость развития и/или расширение горизонта планирования.
Важнее, скорее, разобраться в разведении «человеческой-управленческой» и «технологической» функций. Тимлид обеспечивает слаженную и структурированную работу всей Engineering-команды и служит связующим звеном с другими функциями в компании. Techrocks.ru – это качественный контент, созданный инженерами для инженеров.
Какие вызовы появляются с масштабированием
С грамотным развитием специалистов и/или хорошими наймами на эту роль создается правильный профицит управленческой функции. Для быстро растущего продукта (iDeals растет на 20-30% в год) это суперважно. При росте команды разработчиков неизбежно возникает потребность в функциях экспертного руководства и управления людьми. Для быстро растущего продукта (iDeals растет на20-30% в год) это суперважно. Итак, сейчас в каждой команде у нас 2-3 Back-end Engineers, 1-2 Front-end Engineers, 2-3 QA/AQA Engineers.
И это важная задача менеджмента — понять, какой подход покажет бОльшую эффективность. В целом техническая и бизнесовая части у нас работают в синергии. Нам удается избегать длительных обсуждений для принятия решений, команды становятся продуктивнее и автономнее.
Кого-то можно встретить в сервисной компании, кого-то — в продуктовой, а кого-то вообще только на стыке настоящего Research & Development. Такой подход позволяет нашим Engineering Managers и оставаться в поле технологий, и прокачивать управленческие скиллы, чтобы на всех уровнях улучшать процесс создания решений своей командой. Да, Алексей, как и написал в статье, понимание и подход к этому вопросу у каждой компании свой.
То есть вместе с ростом команды возникает необходимость разделить лидерство на «техническое» и «управленческое». Для достижения результатов команде нужны оба «крыла». Первое — чтобы задавать направление движения в сфере технологий и экспертного развития коллег.
Team Lead vs Tech Lead. В чем разница и зачем разделять эти роли
Второе — для эффективной координации, создания здоровой и продуктивной атмосферы и ориентации на бизнес-цели и результаты. Есть подход, при котором тимлид в инженерной команде — не обязательно инженер, а специалист с развитыми управленческими навыками. Но стоит признать, что не каждый человек без технического бэкграунда может завоевать достаточное доверие команды «технарей», чтобы управлять ими. Тимлид как минимум должен понимать, какие задачи ставит своей команде. Если сказать упрощенно, это один из самых опытных специалистов команды, который предпочитает глубоко погружаться в технические задачи, но не решать сложные вопросы управления людьми.
Team Lead vs Tech Lead: кто есть кто
Он кайфует от этого и не даст команде совершить серьезные инженерные просчеты. Логичный следующий этап — найти в команду инженера с лидерскими качествами, который бы «остался в технологиях». Такой специалист помог бы развивать и поддерживать техническое качество решений команды — Tech Lead. Сам же Алекс, если хорошо справляется с управлением людьми и проектами, становится Team Lead. Привет, я Олег Абрамов, VP of Engineering в продуктовой компании iDeals Solutions.
В iDeals мы уже прошли этап горизонтальной структуры, когда каждая функция имела своего Team Lead, и пришли к вертикальным кросс-функциональным командам. Эта тема требует отдельной статьи, поэтому здесь опишу ситуацию вкратце. Оставшееся время — code review, менторинг и skill-sharing внутри команды. Собрать команду из одинаково квалифицированных специалистов едва ли возможно, всегда будет некий дисбаланс знаний. В некоторых компаниях роль «капитана» может выполнять проджект менеджер.
Кто такой Team Lead
Таким образом, порой out of box thinking дает продуктивные результаты — как с точки зрения бизнеса, так и с точки зрения технологий. Эта позиция имеет смысл уже в разросшейся команде — от 5 человек. Здесь управление связано с непрерывной коммуникацией как с разработчиками, так и с коллегами из других команд, с менеджментом ожиданий, ресурсов и изменений. С ростом коллектива транзакционные издержки растут, поэтому взваливать эти функции на техлида или старшего разработчика будет непродуктивно. И в здоровых командах, где следят за эффективностью, появляется Team Lead.
