О чем

Привет! Я Леонид — технический руководитель направления Публикации вакансий в hh.ru.

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

За последние несколько лет технический департамент в hh сильно вырос. Сейчас в нем уже больше 300 человек и около 50 продуктовых и архитектурных команд.

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

Чем занимается тимлид в hh

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

Если коротко, то роль тимлида у нас в hh.ru заключается в обеспечении эффективной совместной работы команды для быстрой и качественной разработки продукта.

Давайте теперь разберем, что же означают эти умные слова.

Работу тимлида можно условно разделить на три части.

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

Вторая часть работы — управленческие задачи. К ним относятся подбор, адаптация, удержание, увольнение сотрудников, делегирование задач, коммуникация со своим руководителем, командой, другими отделами, управление процессом разработки, развитие сотрудников и многое другое. В зависимости от зрелости команды, уровня сотрудников, умения делегировать и управлять своим временем, тимлид тратит на управленческие задачи от 30% до 70% времени. Данная часть работы еще более важная, чем разработка, ведь грамотно выстроенные процессы позволяют лучше писать код не одному человеку, а целой команде. При этом, вкладываясь в развитие команды и самого себя, у тимлида появляется больше времени на интересные технические и архитектурные задачи.

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

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

Почему важно растить тимлидов внутри компании

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

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

• изучить продуктовый домен своей команды и смежных областей;

• выстроить всю работу с управленческой частью.

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

Со стороны самого разработчика тимлидство — это один из нескольких вариантов развития в техническом департаменте. Развитие сотрудника повышает его мотивацию и лояльность к компании.

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

Процесс развития кандидатов в тимлиды

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

Шаг 1: найти подходящего кандидата

Для начала необходимо найти подходящего кандидата внутри компании, который был бы готов развиваться в сторону управления командой. У нас в компании есть процесс работы с людьми, в рамках которого обсуждается, в какую сторону хотел бы развиваться сотрудник. Супер, если человек сам проявил инициативу и рассказал своему тимлиду, что ему интересно развиваться в данном направлении. Также руководитель команды разработки на встречах в формате one-to-one может сам предложить вариант развития в тимлида подходящему кандидату. Обычно это разработчик уровня senior, который хорошо знаком с кодом и продуктом, самостоятельный, проактивный, не боится брать на себя больше ответственности и хочет развивать наш продукт и процессы.

Еще при появлении новой вакансии тимлида у нас в компании объявляется внутренний конкурс — откликнуться на вакансию может любой разработчик. Это еще один из способов найти потенциального кандидата для развития.

Это все прекрасно, но бывают и случаи посложнее. Может быть и такое, что на вакансию тимлида откликнется внутренний сотрудник, который явно не подходит на данную роль. Например, у него никак не проявляются лидерские качества или он безынициативный, делает только то, что ему сказали, редко берет на себя ответственность. В таком случае сначала надо выяснить у сотрудника, почему он хочет стать тимлидом. Возможно, его интересует только рост зарплаты, и он не видит альтернатив развития. Стоит поговорить с ним про другие варианты: развиваться как технический специалист и повысить грейд в своем направлении, качать навыки архитектора или наставника. Если же сотрудник все-таки хочет стать именно тимлидом, то можно дать ему попробовать возглавить какой-нибудь проект и сделать его от начала до конца. Это позволит сотруднику понять, что данная роль для него не подходит или, наоборот, доказать, что он может справиться.

Шаг 2: выяснить ожидания

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

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

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

Шаг 3: оценить компетенции

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

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

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

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

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

Шаг 4: составить план развития

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

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

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

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

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

Теперь нам важно мониторить процесс и помогать сотруднику двигаться по плану развития. 

Шаг 5: контролировать процесс и давать обратную связь

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

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

Шаги 3-5 повторяются, пока не будут в достаточной мере прокачены все важные компетенции.

Шаг 6: конкурс на тимлида

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

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

В заключение

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

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

Если вам понравился такой подход к развитию своих сотрудников, и вы хотите внедрить подобный у себя в компании, то стоит начать с выработки четких обязанностей тимлида и компетенций, которым он должен соответствовать. Можно взять за основу, например, teamlead roadmap (авторы: Стас Цыганов, Егор Толстой и комьюнити). В нем уже довольно подробно описана суть и значимость обязанностей тимлида, а также способы прокачивания необходимых навыков. Важно учитывать особенности вашей компании и адаптировать компетенции именно под свои процессы, правила, культуру. Также необходимо искать в команде людей, готовых и способных заниматься менторством и развитием других сотрудников. Это могут быть ваши текущие тимлиды. Останется дело за малым — наблюдать за сотрудниками и искать потенциальных кандидатов для развития.

Интересно, а у вас в компании есть системный подход по развитию своих разработчиков в тимлидов? Делитесь в комментариях!