Кто такой техлид и почему он нужен команде

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

Но в нашей индустрии даже градация должностей junior/middle/senior колоссально отличается от компании к компании. Что уж говорить о техлиде, который и вовсе не должность, а роль. Поэтому решили разобраться, что вкладывают в это понятие чаще всего. Заодно очертить зоны ответственности, сформулировать ключевые навыки техлида и понять, наконец, чем техлид отличается от тимлида (Спойлер: тимлид — это тоже роль, поэтому один человек может одновременно быть и техлидом, и тимлидом. А может и не быть).

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

В основе статьи опыт Программного комитета, подкрепленный 50 продуктовыми интервью, которые мы провели. Это нельзя считать масштабным исследованием всей отрасли, но наша выборка достаточно репрезентативна, чтобы заметить некоторые характерные черты.

Начнем с главного.

Техлид — это роль

Причем, часто — неформальная. Однажды инженер оказывается в команде самым опытным и инициативным, он становится неформальным лидером и начинает «топить» за совершенствование инженерных практик. Всё, он уже техлид, и назад, как правило, пути нет.

Если копнуть еще глубже, то это склад ума и особое отношение к ответственности, проактивность. Эти качества трудно привить на пустом месте, но можно создать благоприятные условия, чтобы они проявились. Поэтому, если видите горящие глаза — помогайте им не угаснуть.

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

Чем занимается техлид

Конечно, это сильно зависит от специфики команды и компании и от направления работы самого лида. Наверное, от техлида мобильной-разработки не стоит ожидать помощи в разворачивании Kubernetes (но и такое бывает :)). Мы выделили верхнеуровневые задачи, которые не зависят от стека:

• Определяет стек технологий для конкретных проектов или задач.
• Берет на себя ответственность за внедрение новых подходов к разработке, тестированию, доставке и выбор новых технологий.
• Выстраивает процессы (например, CI/CD, код ревью), внедряет и развивает инженерные практики.
• Минимизирует риски для развития продукта, связанные с техническими ограничениям, преодолевает технические блокеры для бизнеса.
• Определяет технологическую стратегию развития проекта или продукта, работает на перспективу.
• Отвечает за качество реализации, продукта.
• Развивает технические навыки членов своей команды.
• Решает технически сложные задачи, которые другие инженеры в команде не в состоянии решить.

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

Техлид должен фокусироваться не столько на том, какое техническое решение принять, сколько на том, как помочь команде принимать правильные технические решения. Не, как запилить фичу Х, а как помочь команде сделать ее «в 2 раза быстрее, 4 раза дешевле и без багов».

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

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

Главные качества техлида

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

Зато в том, какими качествами должен обладать техлид в самом широком смысле, коллеги оказались довольно единодушны. К TechLead Conf мы подготовим подробную карту развития компетенций техлида, но и верхнеуровневый базис получился очень внушительным.

• Умеет видеть проблемы, замечает в повседневной рутине то, что требует улучшений.
• Ему не безразличны процессы в компании и принимаемые решения.
• Готов взять на себя ответственность за принятие решений.
• Системно мыслит, чтобы принимать долгосрочные решения и работать в условиях неопределенности.
• Ясно доносит свои мысли и обосновывает полезность предлагаемых изменений.
• Является лидером, умеет повести за собой людей и научить их тому, что умеет сам.
• Считается с мнением коллег и умеет договариваться, а иногда и жестко отстаивает свою позицию.
• Может быстро разобраться в предметной области и понимает, как технические решения влияют на реальную жизнь.
• Обладает широким кругозором, держит руку на пульсе современных технологий.

А еще техлид, как и любой высококлассный специалист, должен думать о том, как он думает. Должен понимать ментальные модели и тюнить их.

Должен ли техлид работать руками

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

С другой стороны, если большую часть времени посвящать непосредственно разработке, то может не хватить на что-то из нашего первого списка задач техлида. На определенных этапах становления компании у техлида могут преобладать, например, задачи исследования или менторства. Тогда вряд ли команда должна рассчитывать на то, что техлид возьмет на себя какие-то продуктовые таски. Он может временами работать с кем-то в паре, контрибьютить в open-source или экспериментировать в pet-project. Главное, «не терять хватку» и осваивать новые стеки технологий.

Можно ли без техлида

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

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

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

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

Вы скажете, а как же командная ответственность? А никто и не говорит, что роль не может быть распределенной. Она часто размывается, и тогда можно говорить, что есть не единственный лидер, а лидер во фронтенде, лидер в мобильной разработке, лидер в тестировании и т.д. То есть техлид отвечает за свою доменную область, за один продукт или проект.

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

Чем техлид отличается от других ролей и должностей

Конечно, сравнивать техлида и senior-инженера не совсем корректно, потому что одно — роль, а второе — обычно должность. Senior вполне может быть техлидом, но может и не быть. Ниже мы пытаемся определить, чем отличается инженер в роли техлида от тех, кто эту роль не исполняет, но тоже обладает высоким уровнем экспертизы и ответственности.

Не относитесь к этим сравнениям слишком серьезно, мы знаем, что в разных компаниях все может быть иначе. Но если все же заметите, что к вам относится большинство характеристик техлида, и при этом вы себя им не считаете — добро пожаловать в клуб :)

Техлид vs Senior

Глубокие знания и самодостаточность старшего инженера очень полезны в команде. Но если команда будет состоять только из звезд-одиночек, то командная работа вряд ли получится.

Техлид vs Тимлид

Различие между техлидом и тимлидом одновременно и самое очевидное, и самое расплывчатое. Если спросить об этом человека, который совмещает в себе обе роли, а называется при этом, например, менеджером проекта, то показания получатся путанные.

Но если обратимся к опыту компаний, в которых в команде есть и тимлид, и техлид, то поймем, что тимлид работает с людьми и фокусируется на процессы коммуникации в команде, техлид — с ресурсами и инженерными процессами. Техлид вряд ли будет следить, а не выгорает ли Петя, и точно ли Серёже удобно работать с Васей. А еще вопросы закупки оборудования, участия в конференциях, тимбилдингов, зарплаты и премий — это точно не к техлиду.

Получается, что техлид может не быть тимлидом, но тимлид может быть техлидом. С другой стороны, тимлид может не обладать такими глубокими знаниями, а техлиду точно это нужно.

Поэтому на нашей конференции не будет чисто софт-скилловых докладов о том, как проводить 1-to-1 и строить доверительные отношения в команде, — это оставим TeamLead Conf. Мы будем обсуждать то, как выбрать и внедрить подходящие инженерные практики, как добиться технического совершенства и выстроить инженерные процессы.

Техлид vs CTO

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

Значит (возможно, пока не придумали CTO Conf), на конференции TechLead Conf для CTO будет много полезного. И естественно, это не только доклады, но и возможность обсудить с другими техлидами и CTO современные подходы и проблемные области индустрии.

Как стать техлидом

Если у вас возник этот вопрос (и тем более вы дочитали до этого места), то полдела сделано. Как мы сегодня поняли, техлид — это самый проактивный и ответственный инженер в команде. Поэтому нужно не сидеть на месте, не бояться выходить вперед, брать ответственность, интересоваться миром вокруг, наращивать самый разнообразный опыт.

Вот на что рекомендует обратить внимание программный комитет TechLead Conf:

Алик Курдюков (UnitedTraders): Во-первых, нужна самоорганизация. От инициативности не будет никакой пользы, если вы неэффективно используете свои ресурсы. На мой взгляд, лучшая книга на русском языке на эту тему — это «Джедайские техники» Максима Дорофеева (с основными концепциями можно познакомиться в докладе Максима Дорофеева на РИТ++). Во-вторых, нужно уметь отстаивать свои решения — в этом помогут материалы по продажам, например, книга «Сначала скажите „Нет“» Джима Кэмпа.

Александр Матвеев (Avito): Увлекаться тем, что ты делаешь. Постоянно развиваться, читать книги и статьи, пробовать применять полученные знания на практике — обязательное условие. Постепенно накопится опыт применения подходов и практик и позволит достичь нового качества. А параллельно нужно развивать стратегическое мышление, чтобы лучше видеть перспективы тех или иных технических решений.

Евгений Сабиров (TELEMED.CHAT, ГК ХОСТ): Для начала нужен определённый mindset: в каждый конкретный момент развития процессов понимать, что можно сделать лучше и за счёт чего. А дальше уже изучать конкретные маршруты, какими можно в это «лучшее завтра» прийти. Чем больше маршрутов будет освоено, тем быстрее будут находиться новые.

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

Антон Бевзюк (Raiffeisenbank): Не сидеть на месте и постоянно учиться тому, что интересно самому человеку. Развивать две руки: изучать современные инженерные практики, инструменты, фреймворки и классические дисциплины программирования, о том как грамотно и качественно писать чистый код.

Вьет Нгуен (МегаЛабс): Расширять кругозор и постоянно тюнить свои ментальные модели и инструменты мышления — начните прямо сейчас!

Евгений Иванченко (DODO PIZZA): Чтобы стать техлидом, необходимо глубоко погрузиться в доменную область. В инструменты и технологии, которые используются в этой области. Прокачать необходимые софт-скиллы и не бояться брать на себя ответственность.

Юлия Долбилова (DODO PIZZA): Как стать техлидом, лучше расскажут спикеры на нашей конференции.

Приходите на TechLead Conf, посмотрите чем живут техлиды в разных компаниях и точно сможете оценить, что еще можно подкачать. Или, если хотите поделиться своими наработками и привлечь внимание к тем аспектам работы техлида, которые кажутся вам самыми важными, — присылайте заявку на доклад. Пока это могут быть короткие тезисы с основными идеями, мы в Программном комитете поможем сделать доклад максимально полезным именно для аудитории техлидов.

Подключайтесь к telegram-каналу и чату конференции — в канале публикуем новости, в чате их обсуждаем и спрашиваем ваше мнение о будущих темах и докладах TechLead Conf.

Автор: Travieso

Источник