Привет! Меня зовут Илья Прахт, я тренер на курсах TeamLead, Senior Product Manager, Delivery Manager и COO в OTUS. И сегодня хочу порассуждать с вами о том, как же выбирать тимлидов.
Хочу порассуждать в двух направлениях. С одной стороны, если ты CTO или Delivery Manager, и перед тобой стоит задача назначить нового руководителя в команду – на что смотреть, как сделать этот выбор. С другой, если ты сам инженер и мечтаешь стать тимлидом – как построить свое развитие, как продемонстрировать руководителям, что ты точно готов. Ориентиры заданы, давайте разбираться.
Муки выбора тимлида
Кого обычно ставят тимлидом? Плюрализм мнений здесь зашкаливает. Самыми популярными могут быть такие варианты:
Самый сильный технарь
Лучший организатор
Самый инициативный и проактивный
Самый надежный
…
Список можно продолжать, но эти опции – самые распространенные. А какая из них правильная? Я думаю, вы догадались – ни одна из перечисленных!
Кто такой тимлид
А чтобы найти правильные критерии, давайте сперва определим, кто же такой тимлид. Здесь и далее под тимлидом мы будем понимать руководителя инженерной команды. Именно проектной команды. Играющего тренера.
Если взглянуть на зону ответственности тимлида, то она окажется довольно широкой. С одной стороны, это целиком и полностью вся техническая часть разработки проекта. И не только полнота написанного кода, но и его качество. Отсюда важны правильные процессы, код-ревью, gitflow и т д и т п. За все это отвечает тимлид.
А еще, он ответственен за команду. За всех людей, кто работает с ним. За их производительность, за их мотивацию, за результаты их работы. Вот и получается, и за людей отвечает, и за проект, и еще сам код писать должен. Это ж надо быть готовым к такому, не каждый сдюжит.
Критерий выбора #1 – ответственность
Поэтому, на мой взгляд, основной и главный критерий выбора тимлида – это ответственность. Готов ли человек, которого вы хотите поставить на эту роль, взять на себя все это и затащить. Ответственность в данном контексте – это про уровень решаемых проблем, готовность принимать решения и разбираться с последствиями, желание быть самостоятельным. Вот все это в купе и есть она – ответственность. Повторюсь, главный критерий выбора, на мой взгляд.
Виды тимлидов
Если вспомнить знаменитую модель Адизеса (я не буду здесь ее подробно разбирать, про нее написана куча классных материалов), то можно попробовать выделить несколько самых ярких типажей тимлидов:
Paei → “Самородок” – делает все сам, берет на себя самые крутые и сложные задачи, команде уж как повезет
pAei → “Бюрократ” – вообще не делает никаких тасок, дни напролет тратит на выстраивание процессов и постоянный контроль
paEi → “Фантазер” – мало работает, много мечтает, у него есть классная картинка развития проекта, но она всегда остается где-то там, в будущем
paeI → “Плакательная жилетка” – плюшевый и комфортный руководитель, всегда выслушает и поможет советом, даже если вопрос не про работу, а, например, про выбор обоев в квартиру
PAei → “Человек-проект” – редкий типаж, которого любят эффективные менеджеры, он и сам много кодит, и за командой успевает приглядывать, всем тасочек нарезать, одна беда – за ресурсами людей уже совсем не видит
PaEi → “Техлид” – хороший типаж, если у вас сложный технически продукт и маленькая команда, умеет видеть правильную картину будущего и потом ее реализовывать
pAEi → “Почетный делегатор” – сомнительный типаж, тоже видит будущее, но сделать его не имеет никакой возможности, или желания, все на свете делегирует
pAeI → “Руководитель команды” – хороший типаж, если у вас большая команда, где нужно вкладываться в пипл-менеджмент и успевать следить за всеми задачами
PaeI → “Ментор” – самый что ни на есть играющий тренер, хорош для маленьких команд, успевает и с людьми поработать, и сам чего-нибудь пописать
Какой из этих типажей самый правильный? Если команда большая, то лучше всех подойдет номер 8 – “Руководитель команды”. А если команда маленькая, то номер 9 – “Ментор”. Это, как раз, 2 вида играющих тренеров, в зависимости от их возможностей “играть”.
Так вот, вопрос. От чего будет зависеть типаж тимлида? Порой, от развитых компетенций. Иногда, от поставленных перед ним задач и KPI-ев. Но чаще всего, это очень личная история, и все зависит от пресловутых Soft-Skill-ов, личностных качеств.
Критерий выбора #2 – Soft-Skills
Нужно обеспечить некоторую комбинацию (P+A), чтобы управлять и писать код, и крепкое I, чтобы люди в команде были счастливы и продуктивны. Нужны лидерство, любовь к людям, многозадачность и многое другое.
Так что Soft-Skills – номер 2 в нашем рейтинге критериев выбора тимлида. Это то, что очень сложно развивать, если этого нет, и то, что становится драйвером карьеры, когда их в достатке.
Задачи тимлида
Теперь давайте глубже окунемся в работу тимлида. В его обычный рабочий день. Что там будет? Примерно и очень грубо, можно сказать следующее:
~ 30% – Управление проектом: управление скоупом, распределение задач,планирование и коммуникации со стейкхолдерами
~ 30% – Работа с командой: 1/1, мотивация, разрешение конфликтов, аттестации и ИПР, найм и онбординг
~ 30% – Технические задачи: написание кода, проведение код-ревью, выбор и построение инженерных процессов, решения по архитектуре
Глядя на этот список, хочется спросить: а насколько тут “тренер”, а насколько “играющий”? Иными словами, а сколько во всей этой тимлидской рутине будет менеджмента?
На самом деле, если смотреть комплексно, то на сцену выходит принцип Парето. Действительно, порядка 80% задач тимлида – это про менеджмент. Это регулярный менеджмент, чтобы ставить и принимать задачи сотрудникам. Это пипл-менеджмент, чтобы уделять им внимание и работать с их мотивацией. Это менеджмент процессов, чтобы перфоманс команды был на уровне. И это технический менеджмент, чтобы итоговый результат и поставляемая клиенту ценность была надлежащего качества и в оговоренные сроки.
Критерий выбора #3 – Менеджерские компетенции
Вот здесь только не путайте их с Soft-Skills (так часто делают, зачем-то). Менеджерские компетенции – это Hard-Skills менеджера, ибо есть четкие правила и рекомендации, как управлять чем-то: людьми, проектами. Важно все эти правила, рекомендации знать и исполнять, инструментами уметь пользоваться.
Тимлид – играющий тренер
Ну и снова возвращаемся к тому, с чего мы начали. Тимлид должен писать код. Он не должен быть самым крутым и скиловым в команде. Он не должен быть фулл-стекером, особенно если в проекте технологический зоопарк. Но он должен иметь достаточный технический бэкграунд. Он должен хорошо понимать в архитектуру и принимать основные архитектурные решения. И должен пользоваться авторитетом среди сотрудников, иначе как он сможет ими управлять. Без понимания техники ведь даже задачу нормально не сформулируешь.
Критерий выбора #4 – Технические компетенции
Вот и про технику не забыли. Как видите, первое место ей не досталось (о чем, наверняка, кто-то захочет поспорить), да и второе с третьим прошли мимо. Но вот на почетное четвертое мы ее помещаем. Потому что без технических компетенций тимлидом быть, все равно, не выйдет.
Выбор тимлида
Итак, 4 критерия выбора тимлида мы с вами определили:
Ответственность
Личные качества (Soft-Skills)
Менеджерские компетенции (Management Hard-Skills)
Технические компетенции (Engineering Hard-Skills)
И когда перед нами стоит задача выбора кандидата, по моему опыту и опыту многих моих коллег, следует двигаться последовательно сверху вниз. Если у человека достаточный уровень ответственности, он сдюжит. Если кандидата с необходимой ответственностью нет, смотрите на Soft-Skills, их тяжелее всего качать, поэтому наиболее подходящий кандидат потом, если что, подтянет все остальное. Если идеального мэтча по софтам не случилось, выбирайте по менеджерским скиллам. Ну а если перед вами команда чистых технарей, то берите самого продвинутого, как минимум, на его “прокачивание” в тимлиды уйдет меньше времени. Хотя в пункте 4, я бы смотрел больше на потенциал пунктов 1-3, нежели на текущую технику.
Для наглядности предлагаю изобразить все это в виде такой пирамиды. Назовем ее “Пирамида тимлида” (а что, звучит!)
Логичный вопрос, который должен у вас появится – “а как, собственно-то, проверять все это?” И это очень правильный вопрос! А ответ уже запрятан в самом вопросе – проверять! Вариантов может быть несколько.
Можно делегировать отдельные задачи, тем самым расширяя зону ответственности сотрудника, давая ему возможность продемонстрировать компетенции. Например, назначить потенциального тимлида главным за целый эпик и дать в помощь 1-2 человек. Очень хорошая тренировка и проверка делом.
Можно полностью погрузить его в новую роль (только безопасно), и посмотреть, как будет справляться. Например, поставить заместителем на время отпуска тимлида. И здесь полный Win-Win: и кандидат попробовал себя, и мы увидели, что он умеет, и замена тимлиду есть, может отдыхать спокойно, и откатить все можно безболезненно, если вдруг что пошло не так.
Развитие тимлида
Теперь другая сторона вопроса, которую мы тоже анонсировали в начале статьи – как быть тем, кто хочет стать тимлидом? Что наша пирамида говорит про это? А все актуально, только направление меняется, двигаться нужно снизу вверх.
Сначала нужно качать технику до необходимого уровня. Далее качаться в менеджмент. В обоих случаях все довольно несложно, стандартные Знания → Умения → Навыки. Изучаем теорию, пробуем на практике, закрепляем за счет постоянного применения. Можно самостоятельно, можно через какое-то обучение.
Потом работать над Soft-Skills. Тут уже сложнее. Вообще, для развития Soft-Skills есть 3 основных способа:
Личный опыт – делаете сами и развиваетесь
Насмотренность – смотрите, как делают другие, пытаетесь адаптировать под себя
Рефлексия – осознаете себя и свой комфорт, понимаете применимость тех или иных инструментов, ретроспектируете
На и вишенка на торте – ответственность. Как развивать ее? А ее не нужно развивать. По сути ответственность = ваш уровень зрелости, личностной и профессиональной. А зрелость – это то, что базируется на вашем общем опыте и бэкграунде. Так что, оно либо есть, либо нет. И специально качаться здесь никак не нужно. Работайте над остальными уровнями пирамиды, и верхний будет развиваться сам по себе.
В завершении
Данная статья – некоторое видение, отсебятина, если хотите. Наверняка, у вас может быть иное мнение на такой вопрос, и это прекрасно! Обязательно пишите в комментарии, обогатим вместе эту картинку.
Я постарался здесь собрать в некоторую методологию свой опыт, опыт моих друзей и коллег, опыт моих менти. Опыт реальных людей и реальных кейсов, настоящих шишек и достижений. Надеюсь, получилось добавить наглядности и как-то расшифровать ответ на вопрос, а как, собственно, нужно выбирать тимлидов. И если перед вами встанет такая задача – вы будете знать, как к ней подступиться.
Желаю удачи!
Присоединяйтесь к моему телеграм-каналу Седой директор. Пишу там про менеджмент в IT, отвечаю на ваши вопросы и разбираю ваши кейсы. Системно, наглядно, простыми словами.
А все необходимые навыки для тимлида можно получить на онлайн-курсе в OTUS. Кстати, 14 декабря пройдет открытый урок, на котором участники обсудят еще один важный навык любого лидера — как оставаться продуктивным и не допускать выгорания. Записаться на этот урок можно на странице курса.
Комментарии (8)
Suvitruf
08.12.2023 15:57Если взглянуть на зону ответственности тимлида, то она окажется довольно широкой. С одной стороны, это целиком и полностью вся техническая часть разработки проекта. И не только полнота написанного кода, но и его качество. Отсюда важны правильные процессы, код-ревью, gitflow и т д и т п. За все это отвечает тимлид.
Мне кажется или тут понамешали обязанности, в том числе, и от тех. лида?
ilyaprakht Автор
08.12.2023 15:57Не всегда эти роли делят на разных людей. Я здесь рассматриваю как раз такой пример, когда ты и тимлид, и техлид одновременно
iggr63
08.12.2023 15:57На практике конечно это зачастую тот же человек. Но обычно на небольших проектах с ясной целью и ограниченного масштаба. Типично в водопаде. Когда аджайл - функции тех и тим присваиавются разным людям по умолчанию.
drmiltonfine
08.12.2023 15:57Вообще нет, в том же аджайл не редко, а скорее чаще, чем наоборот - тим и тех лид - одно лицо
ilyaprakht Автор
08.12.2023 15:57Вообще нет никакой корреляции с аджайлом. Вопрос в размере команды и компетенций потенциальных лидов. Если команда до 10 человек и человек способен совмещать эти роли, то лучше одного и ставить
netslow
Спасибо за статью, было интересно читать.
Хотелось бы более развёрнуто послушать про soft skills и менеджерские hard skills, то есть про пункты 2 и 3 Вашего списка.
И, раз уж вы упоминаете модель Адизеса, хотелось бы ссылку, на статью, которую можете рекомендовать, и расшифровку paei.
ilyaprakht Автор
Спасибо за фидбек!
Принято, сделаю более подробное описание