«Не каждая компания имеет реальную необходимость в роли Tech Lead. На самом деле, чем больше общаешься с людьми, работающими в сфере технологий, тем больше понимаешь, что у всех разное представление о том, что такое Tech Lead. Для одних это просто бессмысленная роль, для других — полноценная, вплоть до уровня контрибьютора. Это, а также некоторые другие причины, которые я изложу далее, заставили меня в конечном итоге прийти к выводу, что по-настоящему здоровым инженерным организациям не нужны техлиды.
Ненужная ступенька в иерархии
Общей целью инженеров, как правило, является снижение сложности. Когда речь заходит о коде, думаю, не нужно объяснять, как быстро случается обратное. Часто те самые инструменты, которые призваны сократить объем работы, обеспечить скорость или даже снизить сложность, в конечном итоге оказывают ровно обратный эффект.
Вспомните, к примеру, внедрение jQuery, Angular или React. Во многом благодаря этим библиотекам и фреймворкам в краткосрочной перспективе многие проблемы ушли из нашей с вами жизни. Однако в долгосрочной перспективе это привело к обилию спагетти-кода, появлению непробиваемых монолитов и микрофронтендов, с которыми теперь нужно разбираться.
Бесконечные слои переключателей фич — еще один бич нашего времени. А если не хотите о коде, то просто посмотрите на Agile. В принципе, Agile был призван упростить все процессы, но спросите любого, кому приходилось работать с Jira, и он никогда не произнесет слово «простота». Суть в следующем:
Благонамеренные решения часто не позволяют устранить первопричину проблем, и создают более долгосрочные, глубоко укорененные проблемы в командах.
Стандартное определение техлида все слышали тысячу раз: сотрудник-контрибьютор, который разрабатывает, направляет и внедряет технические решения и улучшения с помощью своей команды разработчиков. Звучит просто и легко, но с такой же легкостью может превратиться в минное поле в инженерной организации.
Престиж
Престижность, любой роли в IT, всегда вызывает споры. Часто встречаются люди, которые считают, что на них ложится вся ответственность, и ни одной выгоды. Это одна крайность. С другой стороны, есть те, кто готов надеть на себя любую роль, лишь бы выдвинуться. Я бы утверждал, что ни одна из этих позиций не является здоровой, и, исходя из собственного опыта, здесь не существует «середины».
В идеале команда состоит из разработчиков всех уровней, от стажеров до сеньоров. Хотя не думаю, что существует идеальное распределение подходящее для всех команд, я считаю, что в команде необходимо как минимум наличие младших и старших разработчиков. Однако если вы внезапно решите «назначить» кого-то техническим лидером команды, то столкнетесь с проблемами, которые могут разрушить саму структуру команды:
- Технический руководитель — это старший разработчик, но у вас, допустим, также есть штатный разработчик-сеньйор, который постоянно не согласен с техлидом. Независимо от того, кто там прав, создается атмосфера противостояния, которая приводит к тому, что техлид будет неэффективен или развалит команду, поскольку люди всегда склонны выбирать чью-то сторону.
- Эффективного менторства не получится. Джуниоры будут все больше путаться в противоречивых указаниях сеньоров, и их разочарование возрастет до того, что они начнут просить о переводе в другую команду.
Если эти две проблемы распространяют на крупную организацию с десятками команд, вы получите то, что многие назовут токсичной инженерной культурой.
Хотя в качестве решения проблемы часто предлагают чередовать людей из команды на роли техлида, со временем я пришел к выводу, что многим людям эта роль либо не подходит вовсе, либо сами от нее отказываются, а другие вроде бы не против, но не понимают ответственности, которая с ней связана.
Назначать техлида может Engineering Manager — если он есть — или существующий техлид. Что само по себе может быть проблематично, поскольку слабый техлид может оказаться непригодным для роли руководителя; или очень высокопоставленный сеньор может захотеть назначить слабого или легко манипулируемого техлида-марионетку, чтобы сохранить контроль.
Если это звучит для вас неприемлемо, помните, что программисты — такие же люди, как и политики, и власть и влияние могут быть чрезвычайно ценными для тех, кто стремится быстро подняться по карьерной лестнице.
Усложняется иерархия
В то время как в одних компаниях должность технического руководителя считается просто «тайтлом», другие вкладывают в нее гораздо больше и определяют ее как роль. В разных организациях она может располагаться на разных уровнях, но, как правило, из того что вижу я, реально роль находится где-то между Senior и Staff Engineer, составляя самостоятельный уровень.
В некоторых случаях роль Staff-менеджера сливается с ролью техлида; а поскольку в командах редко бывает идеальное распределение талантов, то бывают команды, где стать Senior Engineer означает стать сразу и Tech Lead.
Есть компании, которые рассматривают роль Senior Engineer как высший уровень, на котором вы либо уже достигли пика своей карьеры, либо вам предлагают перейти на менеджерскую должность, чего советую избегать.
Роль техлида сама по себе сопряжена с множеством потенциальных проблем, которые так или иначе возникнут, даже при самых благих намерениях:
- У вас внезапно возникает иерархия внутри инженерных уровней, где большинство задач практически не имеет отношения к техническому лидерству. Это лишняя структура для отчетности, особенно в Agile-команде с устоявшимися церемониями, такими как ежедневные стендапы.
- От техлида внезапно ожидают, что он будет архитектором, вездесущим на собраниях, не только проводящим личное время за решениями, но и парящим над всеми задачами и работами, в которых участвует команда, при этом подхватывая запущенную работу, как и любой другой член команды.
- Прозрачность также страдает, так как зачастую техлид будет обладать информацией, которой не владеют остальные члены команды. Иногда это может быть полезно, но это создает очень узкую воронку информации: что если техлид приболеет или застрянет в отпуске больше чем на пару дней? Вы получите неосведомленную команду. А один если техлид отвечает за распространение информации, то увидите, как у вас нарушена структура отчетности.
- Если техлид становится временным EM (Engineering Manager). В неблагополучных командах такое случается часто. Собственно EM уходит в отпуск или заболевает, а его место внезапно занимают техлиды. В таком случае проектная отчетность должна предоставляться техлидами на ступень выше, например, непосредственно Engineering Director, VP of engineering (наиболее подходящему, если их несколько) или даже самому CTO (главному инженеру компании).
Судя по тому, что я вижу и ощущаю в технологическом мире, особенно в Долине и в Доках, роль техлида — это роль, которая больше создает проблемы, чем решает их.
Техлиды перегружены работой, рано выгорают и быстро становятся циниками — которых они опасались в начале своей карьеры. И все это за довольно-таки небольшое дополнительное вознаграждение.
Иногда эту роль называют «ролью с гибридной ответственностью», но я считаю, что мы должны честно признать, что само по себе появление этой роли является симптомом плохого менеджмента и упадка инженерной культуры.
О переносимости опыта
Возможно, вам уже стало очевидно, что все проблемы, перечисленные выше — это именно те, с которыми вы сталкиваетесь или которых пытаетесь избежать, так что, это уже достаточно веские причины, чтобы отказаться от техлидов. Но я думаю, есть еще несколько аспектов, которые необходимо осветить.
В реальном мире иерархия не смешивается с ответственностью.
Как правило, в организации существует два вида реорганизации: добавление иерархии и удаление иерархии. Последнее часто называют выравниванием организации, о котором мы чаще всего говорим, когда происходят увольнения. Но нередко случается и обратное, когда команды и целые организации с большим оптимизмом принимают решения о добавлении ролей и уровней. Такое решение слишком часто сопровождается предположением, что стейкхолдеры возьмут на себя труд все правильно организовать, и поэтому все будет работать как часы, или что само по себе наличие роли поможет в разделении обязанностей.
Однако, когда речь заходит о Tech Lead, я считаю, что это редко бывает так. В хорошо функционирующей организации/команде ответственность за создание качественного, работающего продукта лежит не на плечах одного инженера — неважно, какого уровня, — а на всей кросс-функциональной команде. Не один человек должен собирать информацию от всех стейкхолдеров (чтобы команда знала, что разрабатывать), а все, или по крайней мере они знают, что нужно сделать, и какие проблемы предстоят.
К слову о стаже: каким бы опытным ни был техлид, его опыт не всегда применим 1:1 в любой ситуации. Например, микросервисная архитектура может не подойти для бэкенда, а микрофронтенд — для фронтенда. Или, если команда создает что-то экзотическое, например приложение Zoom, вам приходится проявлять творческий подход. Если техлид принимает решения и разрабатывает архитектуру технических подходов в одиночку, это может привести к плачевным последствиям.
Вышеперечисленное также является скоплением низких возможностей. По моему опыту, для продвижения по карьерной лестнице необходима прозрачность в организации. Руководителю легко перевести человека с младшего на средний уровень, но в дальнейшем становится все сложнее обосновать повышение, не имея видимости за пределами его команды. При наличии техлида у остальных сотрудников остается меньше возможностей блеснуть, похвала может быть направлена не по назначению, поэтому члены команды, которые одинаково усердно работали над достижением целей, остаются в тени Техлида. Этого, конечно, можно избежать, но для этого нужен очень зрелый руководитель, уделяющий большое внимание команде.
А нужно вот как:
Позвольте мне закончить на важной ноте. Я понимаю, что наступлю на пальцы многим. По сути, я хочу сказать, что технологическая индустрия в целом делает все неправильно (по большей части), и это продолжается уже давно, и убрать техлидов — это не решение проблемы.
Но это не значит, что ваш техлид делает что-то плохо. Дело не столько в том, что и как делает техлид, сколько в самой организационной структуре, которая получается с его участием.
Я всегда рассматриваю скиллы как инструменты в ящике. Чем больше их у человека, тем больше его набор инструментов, тем лучше. Но электрик не берет с собой на работу набор инструментов сантехника, так и набор инструментов менеджера может быть совершенно бесполезным или даже опасным, будучи примененным в неправильном контексте.
Навыки технического руководителя бесконечно полезнее в контексте проекта, чем в контексте команды.
Я предлагаю не иметь техлидов, либо не иметь их вообще, либо иметь только менеджеров проектов, выполняющих эти обязанности. Какой вариант вы выберете, зависит от инженерной культуры и только от нее. Из моего более чем десятилетнего опыта я могу сделать один вывод: чем здоровее инженерная культура в компании, тем меньше человек ориентируется на тайтлы и назначенные обязанности. Поработав в командах, в которых не было техлида, но при этом они показывали отличные результаты даже в условиях большой организации, я могу с уверенностью сказать, что для многих команд абсолютно реально и было бы просто полезно никогда не создавать роль техлида (и даже лида проектов).
В этом сценарии каждый член команды получает возможность использовать все имеющиеся у него навыки, учиться лидерству, выходя вперед в любых обстоятельствах, которые этого требуют. Такая установка способствует взаимному уважению, полной прозрачности, как командной, так и индивидуальной видимости во всей организации. А менторинг становится естественной частью командной работы, повседневной — а не индивидуальной целью на конец года для потенциального повышения.
Если у вас так, то можете быть уверены, что у вас сильная инженерная культура, стоящая на прочных столбах — общеорганизационных соглашениях. Можете не верить, но даже такие простые вещи, как одинаковые правила линтинга и форматирования кода, или единый этикет рецензирования кода, но установленные для всех команд, могут оказать ощутимое и долгосрочное влияние на инженерную культуру.
Но, конечно, команда или организация может быть еще не готова к этому или просто слишком велика чтобы провести быструю реорганизацию. Вот тогда-то и пригодятся Project Leads. Это тоже роль, только без иерархии. Наличие нескольких Project Leads открывает возможность для лучшего из них и самого заинтересованного в проекте — занять позицию высшего технического менеджера. И тогда-то будет хорошо, встретятся желание и ответственность. Внезапно выяснится, что дело не в том, чтобы руководить всеми и всяческими техническими решениями своей команды, а в том, чтобы обеспечить успех проекта.
Еще одно преимущество лидов проектов перед техлидами — их ограниченный масштаб, как по техническим задачам, так и по времени. Большинство проектов, за которые берутся команды, не длятся годами, если по Agile. В течение нескольких месяцев или даже недель проект может быть завершен, а руководитель проекта может либо возглавить другой проект, либо просто передохнуть некоторое время и присоединиться к кому-то.
Выбор зависит от того, насколько сильна, по вашему мнению, инженерная культура в вашей организации. Возможно, над ней еще нужно поработать. А может быть, вы даже не обсуждали этот вопрос, просто у вас есть чувство, что что-то пошло не так. Сильную инженерную культуру сложно создать, и на это требуется время, но я твердо уверен, что наличие техлидов не способствует формированию здоровой культуры.
Секрет процветания инженерных команд заключается не в иерархии, а в сильной, здоровой инженерной культуре — а такая культура требует как можно меньше иерархии.»
