Рубрика: Практика лидерства · Блок: Лидерство и командная динамика

Тимлид: роль, компетенции и кого назначать на эту должность

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

Решение: Лидерство и развитие руководителей, ИТ-команды

Кто такой тимлид простыми словами

Тимлид (от английского team lead — «ведущий команды») — руководитель небольшой команды, чаще всего в разработке программного обеспечения. Обычно у него от трёх до десяти человек: разработчики, тестировщики, иногда аналитики и дизайнеры.

Главная задача тимлида — чтобы команда стабильно выпускала результат нужного качества. Для этого он распределяет задачи, договаривается с заказчиками и соседними командами о сроках, снимает препятствия, следит за тем, чтобы люди росли и не выгорали. При этом тимлид остаётся близко к технике: понимает архитектуру, участвует в проверке кода коллег (ревью), помогает в сложных технических решениях.

Именно это сочетание — человек одновременно ещё специалист и уже руководитель — делает роль тимлида одним из самых трудных этапов карьеры в ИТ.

Чем тимлид отличается от техлида и руководителя отдела

Названия ролей в разных компаниях пересекаются, но обычно различие такое:

В небольших компаниях тимлид часто совмещает и роль техлида. Чем больше команда, тем сильнее его работа смещается от кода к людям.

Что делает тимлид каждый день

Типичный набор задач тимлида:

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

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

Какие компетенции нужны тимлиду

Компетенции тимлида удобно разделить на три группы.

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

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

Личностные. Устойчивость к неопределённости и постоянным переключениям, внимание к людям, готовность брать ответственность за чужие ошибки перед заказчиком. Как такие качества описывают в профиле роли, видно на примере профиля должности программиста: для тимлида к нему добавляются управленческие требования.

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

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

Сильный специалист нередко продолжает решать задачи сам — так быстрее и надёжнее. Команда при этом не растёт, а тимлид перегружен и работает по вечерам. Этот сценарий подробно разобран в статье «Эксперт, ставший боссом».

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

Кого назначать: признаки готовности к роли тимлида

Готовность к роли видно по поведению ещё до назначения. Полезно посмотреть, делает ли кандидат следующее уже сейчас:

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

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

Что покажут DISC, эмоциональный интеллект и стили мышления

Поведенческие признаки дополняет диагностика. Она не решает за руководителя, но показывает, где кандидату будет легко, а где придётся прикладывать усилия.

• Стиль поведения по DISC. Человеку с выраженным Соответствием обычно легко даются качество, стандарты и ревью, но может быть труднее быстро принимать решения при неполных данных. С высоким Доминированием — наоборот: скорость и решительность есть, а терпения к долгим обсуждениям меньше. Подробнее — на странице DISC для развития руководителей.
• Эмоциональный интеллект показывает, насколько человек осознаёт свои эмоции, замечает состояние людей и управляет своими реакциями. Для тимлида это одна из ключевых зон: встречи один на один, обратная связь, конфликты в команде.
• Стили мышления (ACI) показывают, на что человек смотрит в первую очередь: на людей, на практическую пользу или на системы. Разработчик, который прежде всего видит систему, может не замечать, как команда реагирует на изменения. Знать это заранее полезно и ему, и его руководителю.

Как всё это собирается в оценку для ИТ-ролей, — на странице оценки ИТ-специалистов и команд.

Как подготовить переход в роль тимлида

Переход проходит мягче, если его готовить заранее:

1. Пробная ответственность. До назначения дать кандидату вести небольшой проект или наставлять новичка.
2. Ясные ожидания. Описать, что будет считаться успехом в первые три и шесть месяцев: не количество кода, а результат команды.
3. Снижение технической нагрузки. Явно договориться, какую долю времени тимлид тратит на код, а какую — на людей.
4. Наставник. Опытный руководитель, к которому можно прийти с трудной ситуацией.
5. Обучение. Базовые навыки: встречи один на один, обратная связь, делегирование, разбор конфликтов.
6. Обратная связь от команды. Через несколько месяцев — короткий опрос команды или оценка 360, чтобы увидеть, что получается.

Ошибки первых месяцев

Типичные ошибки начинающих тимлидов повторяются от компании к компании:

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

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

Частые вопросы

Кто такой тимлид простыми словами?

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

Чем тимлид отличается от техлида?

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

Нужно ли назначать тимлидом лучшего разработчика?

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

Как понять, что разработчик готов стать тимлидом?

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

Какие ошибки чаще всего делают начинающие тимлиды?

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