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

Определение

Короткое: Технический лидер – это инженер-программист, который отвечает за управление командой и поддержку технического направления.

Длинное: Технический лидер (или техлид) — это инженер-программист, который отвечает за управление командой и поддержку технического направления. Поддержка технического направления включает в себя наличие технического видения, решение технических противоречий и управление качеством результата работы команды. Эффективный технический лидер гарантирует, что команда использует соответствующие инженерные методы (такие как CD и автоматизированное тестирование), инвестирует в постоянное совершенствование инструментов или сокращение технического долга, а также гарантирует, что система развивается в соответствии с меняющимися потребностями и окружающей средой.

Иногда позиция тимлидера может быть поделена между несколькими людьми, но очень редко делится позиция техлида. Технический лидер может руководить командой совместно с такими специалистами как Product-менеджер, инженер-менеджер или тимлид. Где инженер-менеджер или тимлид фокусируются на развитии людей и росте команды, технический лидер фокусируется на техническом росте членов команды и системы. Фокус техлида лежит на руководстве техническим направлением и качеством работы команды. Также у них могут быть дополнительные обязанности в зависимости от конкретной команды.

В примере выше у команды может быть Product-менеджер, инженер-менеджер и техлид. Лидерство разделено на три роли, но каждая из них обеспечивает свое направление. В данной ситуации технический лидер больше фокусируется на технических аспектах. Остальные руководители будут активнее участвовать в обсуждении и принятии решений.  Они будут наблюдать и управлять качеством кодовой базы по мере ее развития и технического роста команды.

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

Что остается в любой команде несмотря на ее состав – это техническое превосходство техлида. Эффективный техлид работает над техническим видением команды. И вместе с командой они обновляют, развивают его и претворяют в жизнь. Техлид постоянно работает с кодом, чтобы принимать обоснованные решения, выявлять технические риски и выстраивать доверительные отношения с разработчиками. В своей презентации «The Geek’s Guide to Leading Teams» я предлагаю проводить над кодом минимум 30% времени.

Не просто тимлид

На заре своей карьеры я работал в команде, где были техлид и тимлид. У тимлида не было хороших познаний в архитектуре. И они могли бы вместе писать код, но выбрали способ добавлять команде ценность другим путем. Они очень много времени уделяли развитию людей. Тимлид очень часто общался один на один с людьми, которые работали над обратной связью и развивали свою карьеру. Руководители активно организовывали мероприятия по укреплению психологической безопасности и доверия в команде. Тимлид встречался со стейкхолдерами не из команды, но поддерживал хороший информационный поток и устранял блоки.

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

Больше практики, чем у инженера-менеджера

«Вы управляете вещами и руководите людьми.»

- Грейс Хоппер

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

• Поддерживают продуктивную рабочую среду для команд разработчиков;

• Выбивают бюджет на развитие и поддержку бизнес-целей;

• Представляют технологические перспективы на уровне руководства или совета директоров;

• Создают или координируют рабочие программы (реализуемые в рамках разработки);

• Занимаются рекрутингом и удержанием персонала для удовлетворения потребностей команды или ИТ-персонала.

Инженер-менеджер может быть как одним на команду, так и одним на несколько команд. У многих из них может даже не быть опыта разработки. Вместо этого они могут быть Product-менеджерами, QA или другими специалистами, вовлеченными в разработку ПО.

Техлид – хороший архитектор

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

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

Эффективный архитектор – это хороший техлид. Он понимает, какова цель команды, и создает соответствующее архитектурное видение. Он работает с командой, корректирует курс по мере того, как команда узнает больше о задаче и технологии, выбранной для ее решения.

Какими ключевыми навыками должен обладать технический лидер?

Несмотря на то, что сферы технического руководства могут варьироваться, необходимые навыки – нет. Технический лидер должен сформировать сбалансированный набор навыков в следующих областях:

• Разработка – техлид должен иметь опыт работы в качестве разработчика. Он должен знать, как писать код и как выглядит хороший код. Он должен быть в состоянии помочь своей команде с любыми техническими проблемами, даже если он не эксперт в этой сфере.

• Архитектура – только один этап построения работающей системы. Технические лидеры должны иметь более широкое понимание того, как программное обеспечение вписывается в общую систему. Они должны понимать как ПО будет разворачиваться, управляться и эксплуатироваться на продакшене.

• Лидерство – эффективный техлид должен обладать сильными лидерскими качествами, даже если не он формально стоит во главе команды. Такие лидерские качества, как коучинг, влияние и делегирование полномочий, являются ключом к успеху.

«Технический лидер – это инженер-программист, ответственный за руководство командой и поддержку технического направления.»

- Определения техлида (от @patkua)

Технический лидер – это инженер-программист, ответственный за руководство командой и поддержку технического направления. Технический лидер может руководить командой совместно с такими специалистами как Product-менеджер, инженер-менеджер или тимлид. Но только техлид фокусируется на технических аспектах, на том «как сделать». Эффективный техлид сочетает в себе сильные лидерские навыки, навыки архитектора и разработчика. Он создает в команде общее техническое видение и несет ответственность за качество технических результатов команды. 

Почему уход сотрудника из компании часто становится катастрофой? Как готовиться к выходу из коллектива компании и сотруднику? Почему увольнение должно быть готово в первый день работы?

Ответы на эти и многие другие вопросы даст эксперт OTUS - Александр Пряхин, в рамках бесплатного демо урока курса "Team Lead 2.0". Записывайтесь на урок по ссылке.