Что такое тимлидинг и как он поможет в бизнесе

Интродукция.

Всем здравствуйте. Меня зовут Петросов Сергей, я руковожу разработкой партнёрских сервисов в Arassa Nusga. О роли тимлида сказано и написано много: бесконечное число книг, технических и не очень, тренинги, конференции, каналы и прочее. Проблема в том, что ни одна книга не даёт рецепта «серебряной пули», которая позволила бы эффективно управлять людьми и процессом разработки, не совершая ошибок. Поэтому каждый тимлид со временем создаёт свой фреймворк работы, который помогает справляться с ежедневной рутиной, при этом не забывать про развитие, делать это эффективнее и совершать меньше ошибок. Форма у этого фреймворка может быть любая: где-то его формализуют и делают частью бизнес-процессов компании, а где-то он может существовать в виде чек-листа в заметках тимлида. Главное, чтобы он был, чтобы им пользовались, актуализировали и развивали. В этой серии статей я хочу описать свой взгляд на работу тимлида, поделиться опытом и лайфхаками.

Team leader (тимлид) — это IT-специалист, который управляет командой разработчиков, владеет технической стороной, принимает участие в работе над архитектурой проекта, занимается ревью (проверкой) кода, а также разработкой некоторых особо сложных заданий на проекте. На мой взгляд, обязанности тимлида можно условно поделить на четыре области:

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

• Найм
• Адаптация
• Развитие
• Удержание Мотивация
• Увольнение Расставание

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

1.Найм

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

Поиск:

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

Первичный отбор:

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

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

Собеседование:

Собеседование кандидата, пожалуй, самый важный шаг в процессе найма как для самого кандидата, так и для компании. Именно от того, как пройдёт собеседование, зависят дальнейшие шаги, размер компенсации в будущем, команда, в которой будет (или не будет) работать кандидат. Про то, как готовиться, проводить и проходить собеседования написано много материалов, не буду перечислять их здесь. Остановлюсь лишь на важных моментах для тимлида. На мой взгляд, собеседование должно быть:

• структурированным;
• универсальным;
• достаточным для принятия решения.

Структура собеседования

Цель собеседования — ответить на вопрос, подойдёт ли кандидат компании и компания кандидату. Чтобы ответить на него, собеседование должно быть структурированным как с точки зрения расписания, так и с точки зрения содержимого. Расписание, которое я выработал для себя (исходя из длины собеседования 1,5 часа):

Секция	Продолжительность
Рассказ о компании	15 мин
Обсуждение резюме	15 мин
Технические вопросы	50 мин
Вопросы кандидата	10 мин

Рассказ о компании:

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

Обсуждение резюме:

Главная цель «совместного чтения» резюме для меня — понять, ценный ли сотрудник передо мной. Поэтому в ходе этой секции я акцентирую внимание на сменах места работы/должности и пытаюсь понять, передо мной pulled или pushed кандидат. Все знают, насколько тяжело найти действительно профессиональных специалистов, поэтому опытный руководитель всегда будет двигать сотрудника по карьерной лестнице, будет звать его с собой при смене работы, расширять область ответственности (в одной из компаний это называлось being pulled). И наоборот, если сотрудник ничего особенного из себя не представляет, руководитель легко его отпустит, не будет давать новых обязанностей и повышать в должности (being pushed).

Технические вопросы:

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

• базы данных;
• основной язык;
• инфраструктура, сеть, протоколы;
• алгоритмы;
• проектирование архитектуры.

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

Ещё я уверен, что необходимо принимать решение по итогам одного собеседования, а не растягивать этот процесс на месяц(ы) (довелось видеть и такое) с бесконечным числом очных собеседований с командой, СТО, HR-ами и пр. На мой взгляд, такой подход — это перекладывание ответственности и боязнь принять неправильное решение. Плюс, не стоит забывать, что процесс поиска обоюдный: компания оценивает кандидата, а кандидат компанию, и пока вы назначаете N-ноe по счету собеседование, кандидат может просто-напросто устать и выбрать другого работодателя.

Есть еще такая практика, как тестовый день, которая активно практикуется, например, в Dodo. Идея заманчивая, но требует дополнительной подготовки и трудозатрат.

Сбор рекомендаций:

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

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

• При каких обстоятельствах познакомились/расстались с кандидатом?
• За что конкретно отвечал кандидат в проекте?
• Хотели бы вы снова работать вместе (наняли бы сотрудника к себе в команду снова)?
• Если бы можно было поставить оценку за его/её работу от 1 до 10, какую бы поставили?
• Есть ли еще что-то, о чём мне стоит знать (персональные предпочтения, черты характера)?

Оффер:

Итак, кандидат успешно прошел стадии отбора и собеседования, и компания готова сделать оффер. Тут у меня есть два правила:

• Делай быстро.
• Не жадничай.

Не секрет, что сейчас рынок ИТ-вакансий — это рынок кандидата. Много компаний со своими бюджетами и дэдлайнами соревнуются за перспективных кандидатов. Поэтому, если принял решение о найме — озвучь его кандидату, формальный оффер можешь прислать позже. Можешь дать человеку sign up bonus — дай! В моей практике даже был случай, когда компания компенсировала годовой бонус предыдущей компании кандидату, чтобы не ждать его до конца года.

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

2.Адаптация

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

Если сотрудник адаптируется быстро, то он быстрее выйдет на полную производительность и будет работать с удовольствием. Если адаптируется медленно, то может так и не интегрироваться в команду, и, вероятно, почувствовав себя «не в своей тарелке», покинет компанию. Поэтому тимлиду особенно важно управлять процессом адаптации сотрудников в команде. Для себя я выделил три момента в адаптации сотрудников:

• мероприятия до выхода сотрудника;
• онбординг в первые дни;
• сопровождение в первые месяцы.

3.Развитие

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

Но если ваша компания не из таких, и необходимо строить всё самому с нуля, то, на мой взгляд, у тимлида должен быть хотя бы высокоуровневый индивидуальный план развития (ИПР) для каждого сотрудника. Цели для этого плана предлагает обычно сам сотрудник, и после обсуждения с лидом составляет более низкоуровневый с конкретными задачами. Прогресс выполнения обсуждается с лидом на встречах one-to-one.

4.Мотивация

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

• в мотивации, как в пирамиде Маслоу, есть «базовый уровень», этакий «гигиенический минимум»;
• материальная мотивация (деньгами) имеет предел действия;
• нематериальная мотивация — самая сильная.

«Гигиенический минимум» в мотивации — это те базовые вещи, без которых вы вряд ли найдёте сотрудника. В сегодняшних реалиях это, например, рыночная зарплата, ДМС, Macbook, современный стэк технологий, гибкий график. Если у вас в компании нет этих базовых вещей, не пытайтесь мотивировать сотрудников высокими целями: в лучшем случае вы потратите время впустую, а в худшем увеличите градус раздражения сотрудников.

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

5.Расставание

Как бы вы ни старались мотивировать и развивать сотрудников, иногда приходится с ними расставаться в силу разных причин. Для себя я выработал три правила в этих случаях.

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

Второе: процесс увольнения лид должен проводить сам. Ни в коем случае нельзя делегировать его HR-ам, руководству или кому-либо ещё.

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

Заключение

В этой статье я поделился своей точкой зрения на обязанности тимлида при работе с людьми, и тем, какие техники я использую, формируя команду, развивая и мотивируя сотрудников. Делитесь своим опытом в комментариях. В следующих частях этой серии мы посмотрим на другие области ответственности тимлида, так что, как говорится, “stay tuned.”

Назад