Должен ли тимлид писать код?

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

Летом 2024 года я работала на стенде Купера на Saint TeamLead Conf++. У меня было несколько карточек с вопросами для обсуждения с тимлидами. Тот самый вопрос — «Должен ли тимлид кодить?» — вызывал самые увлекательные беседы. Примерно 50% из тех, с кем я разговаривала, изначально настаивали на том, что тимлид должен оставаться кодером, однако по мере дискуссии многие перетекали на тёмную сторону. Тогда я подумала, что мои аргументы могут быть полезными и для читателей на Хабре.

Дисклеймер: всё, о чём я пишу далее, — моё личное мнение, основанное на десяти годах в менеджменте. Если у вас другой опыт, буду рада обсудить его в комментариях 🙂

Подмена понятий

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

Продакт-менеджер решает, как будет развиваться продукт, над которым работает команда: определяет целевую аудиторию, анализирует конкурентов и юзеров, следит за метриками.

Техлид фокусируется в первую очередь на технических аспектах: принимает ключевые технические решения, определяет архитектуру и технические стандарты в продукте.

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

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

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

Тяжела жизнь тимлида, который ещё и техлид

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

Тимлиду, который вышел из разработки, нужно перестать воспринимать себя как разработчика, изменить отношение к своей деятельности и к её результатам.

Мне нравится теория, которую продвигает Слава Панкратов — бизнес-тренер и сооснователь школы для менеджеров и тимлидов «Стратоплан». Он говорит, что каждый человек, который находится у тебя в непосредственном подчинении, требует 20% твоего времени. Если под менеджером пять человек и каждый получает законный кусок внимания от руководителя, то всё, время кончается. Соответственно, кодинг, ревью и прочие технические задачи — это уже овертайм, который часто приводит к выгоранию. А если у тебя пять человек и ты не овертаймишь — эти пятеро недополучают твоего внимания, но ты не знаешь об этом.

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

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

А как же разработческая хватка?

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

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

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

Ещё один респондент написал: «Когда тимлид продолжает писать код, возникает вопрос времени, уделяемого техническим задачам, и коммитов. Если время не регламентировано — как его учитывать в капасити команды? В одном спринте 40 сторипоинтов, в следующем — 10. В итоге производительность команды всё время плавает, и предсказуемость падает». Здесь я соглашусь: тимлид в любой момент может упасть в чисто менеджерские задачи и бросить код, который взял на спринт. Тимлида лучше не учитывать при распределении приоритетных задач.

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

Кто-то говорит, что тимлид должен иметь возможность купировать инциденты, проводить менторинг через код, транслировать наиболее современные и эффективные подходы к решению задач. Однако а) всё это может делать выбранный тимлидом техлид; б) тимлид не может быть хорош в любом стеке, соответственно — тимлид и техлид в одном лице подойдёт только команде с одним стеком. Если в команде не только разработчики разного стека, но и аналитики, дизайнеры, тестировщики — мы же не будем говорить, что тимлид должен профессионально менторить ещё и их?

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

По моему убеждению, тимлид не должен писать код на работе, потому что это может навредить его полноценному функционированию в роли менеджера. Но можно писать код в свободное время, если это приносит удовольствие и никак не мешает тимлидству.

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

Тимлид, который не умеет программировать

В Купере я ещё не встречала тимлида, который не умел бы программировать и не был бы выходцем именно из разработки. Тем не менее я считаю, что тимлидство — не ступень карьерной лестницы разработчика (в отличие от техлидства).

Стать из разработчика тимлидом — не вертикальный, а горизонтальный рост. Это превращение в специалиста другой профессии.

И, раз это другая профессия, стать успешным лидером для команды может даже тот, кто ни разу не открывал редактор кода.

Конечно, для работы в IT человек должен понимать азы: как работает бекенд и фронтенд, как работает тестировщик, как работает аналитик и т. д. Полезно знать, как задачи ранжируются по сложности и насколько что трудозатратно. Условно, если дизайнер говорит, что ему нужно три недели на отрисовку одной кнопки, надо смекнуть: что-то идёт не так. Да, пасти котов, то есть развивать хардовые скиллы сотрудников, могут только такие же коты; но единую и вдохновлённую команду из котов, собак и хомячков может сделать хоть кенгуру.

Основу роли тимлида составляют всё-таки развитые коммуникативные навыки, способности к планированию, многозадачность. Вдобавок управление приоритетами: надо понимать, чего хочет бизнес. Прямо ставить себя на место бизнес-заказчика и следить за тем, чтобы приоритеты команды учитывали его потребности.

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

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

Делегируйте с удовольствием

Хотите стать тимлидами из разработчиков даже после моей статьи? 🙂 Напишите на всех возможных поверхностях вокруг себя слово «делегирование». Скорее всего, быстро изменить свои нейронные связи не получится, и вы будете пытаться работать с кодом, потому что это ваша привычная деятельность. Там подхватил ревью, здесь сел чистить код — день пролетел, а в основных задачах и конь не валялся.

Научитесь лениться, когда дело касается кода. У вас есть специально обученные люди, которым можно передать любую задачу технического характера. Забудьте фразу «Я сам(а)» и будьте просто коммуникатором. Ваша роль — сделать так, чтобы разработка шла по плану и была согласована с бизнес-целями, а заряженная команда показывала максимальный перфоманс. Кодить при этом для себя или нет — уже не так важно (опять же — если должность не объединяет в себе роли тимлида и техлида).