Играющий тимлид

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

Кто ты, воин?

Ну типа представьте, у вас есть лид-менеджер, который еще и может в любой момент занырнуть (да-да, занырнуть) в код и решить сложную техническую задачу и потушить пожар своими руками (ну сделать например что-то типа git reset --hard HEAD~10). Или вот есть самый опытный синьор, который всем раздает направо и налево за кодстайл и документацию, но до играющего лида он даже не докопается (тут конечно надеюсь, что именно по причине скилловости последнего).

Также этот же чел спокойно поймет, почему мы не делаем калибровку модели, когда оптимизируем метрику Gini, и конечно же при этом попросит поглядывать на PR-AUC, чтобы не уронить полноту. То есть буквально чел переживал все трудности, с которыми сталкивалась и не сталкивалась (и возможно не столкнется) команда.

Главная проблема не увлечься

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

В чем могут начаться проблемы:

▫️Играющий тимлид может стать бутылочном горлышком, подвязав на себя много задач, когда без его погружения могут тормозиться задачи
▫️"Сделаю сам", или еще хуже - микроменеджерство. Вместо того чтобы дать команде развиваться, он делает задачи за нее. Люди не растут, если за них решают самые интересные и сложные проблемы.
▫️Ну и конечно же повышенный риск выгорания. Пытаться успеть и менеджерить, и кодить в полном объеме звучит как 16 часов работы в день.

Почему тогда вообще возникает такая роль?

Модель играющего тренера эффективна (особенно в небольших командах), если соблюдать правила:

▫️Основная работа - люди и процессы
▫️Главная задача лида, это убирать препятствия, обеспечивать команду всем необходимым и помогать людям расти
▫️Руками - только в критических случаях (например, при исследовании новой технологии (R&D) или в реальном продакшен-инциденте)
▫️Не забирать у команды плановые задачи!
▫️Цель - не написать код, а помочь команде писать его лучше (код-ревью, парное программирование, менторинг в помощь)
▫️Осознанно ограничивать время на код и технические штуки

С ростом команды доля менеджмента неизбежно растет. Важно сознательно оставлять 15-20% времени на погружение вглубь, чтобы не терять хватку, но не в ущерб основным обязанностям.

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

Если бы было что-то одно, на чем бы я предложил сфокусироваться, то это:

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

С ростом команды роль играющего тимлида неизбежно трансформируется:
▫️Больше внимания стратегии и планированию
▫️Фокус на развитие сотрудников
▫️Техническое участие становится более точное и лишь при необходимости

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

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

#softskills #career