Тимлид или техлид

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

На самом деле, в здоровой команде тимлид (Engineering Manager) и техлид (Tech Lead) это две части одного целого. Типа инь-янь.

Го разбираться.

▫️Тимлид (Engineering Manager)

В фокусе - люди и процессы. Его задача создать среду, в которой инженеры могут максимально эффективно работать и расти, по сути отвечая на вопрос: «Как мы работаем?».

У него может быть много 1-1, встречи с HR по найму, встречи с продактами по планированию на квартал (год) вперед, либо например планирование спринта с командой. Также могут быть даже собесы на разные позиции, обсуждение бюджетов команды или Performance Review.

По таскам в том числе могут быть: найм, онбординг и увольнение, развитие и мотивация команды, решение «человеческих» проблем (выгорание, конфликты, низкая вовлеченность). Также устранение блокеров, выбивание ресурсов, взаимодействие с другими командами и коммуникация со стейкхолдерами.

▫️Техлид (Tech Lead)

Здесь в фокусе качество продукта. Его задача - обеспечить техническое совершенство, надежность и масштабируемость того, что делает команда. Он отвечает на вопрос: «Что и как мы делаем?».

Если у тимлида больше менеджерский работы, то у техлида среди встреч может быть: обсуждение архитектуры новой фичи с командой (System Design), сессия парного программирования с джуном, рассказ о последних иследованиях, которые могут пригодиться для проекта. Также может быть встреча с оптимизацией бэклога/техдолга, обсуждение проекта, выступление на внутреннем митапе, и даже забитые слоты под 2-3 часа написания кода (Deep Work).

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

▫️Власть

Если у тимлида область влияния является формализованной и административной, то у техлида власть скорее за счет экспертизы и авторитета. Он влияет своими знаниями и мнением. Но не стоит забывать о важности прямого формального руководителя. От него могут зависеть и премии, и продвижение по карьерной лестнице. Для техлида здесь скорее будет задача в том, чтобы донести необходимую точку зрения и видение до тимлида.

▫️Скиллы

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

С точки зрения техлида я бы упомянул глубокое знание специфики работы и технологий, System Design, архитектурные паттерны, умение декомпозировать сложные задачи, навыки менторства и способность четко доносить сложные технические идеи.

▫️Итого

Команда может быть технически сильной, но без тимлида быстро потерять свою эффективность от выгорания, и не понимания своих целей, целей компании и карьерных перспектив. Без техлида команда может быть счастливой и дружной, но при этом медленно тонуть (если кто утонет, в бассейн больше не пустят) в техдолге и принимать неоптимальные архитектурные решения.

Го огонечки за техлида, сердечки за тимлида

#softskills #career