Фантастические тимлиды и где они обитают

в 13:41, , рубрики: интервью, Карьера в IT-индустрии, найм, управление персоналом

Всем привет! Меня зовут Анатолий Панов, я работаю в ИТ уже больше 15 лет. За это время прошел путь от разработчика до руководителя тимлидов. Работал в таких компаниях как Badoo, Lazada. С начала этого года я в Авито. Руковожу разработкой новых проектов и разработкой для вертикалей Авто и Недвижимость.

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

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

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

Фантастические тимлиды и где они обитают - 1

С чего начать?

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

До этого мне не приходилось заниматься наймом тимлидов. У меня в командах они появлялись более традиционным способом: всегда были ребята, которые показывали себя хорошо в деле, и мы повышали их.

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

  • Составить требование, профиль кандидата.
  • Найти кандидатов на рынке, понять, кто из них подходит к профилю.
  • Провести очное интервью.

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

Составляем профиль кандидата

Чтобы запустить поиск кандидатов на вакансию, у нас должен появиться профиль кандидата, документ, в котором написано, что за позиция, кого мы на нее ищем, цели кандидата, которые будут стоять перед ним в ближайшее время, и навыки, которыми он будет обладать.
Мне повезло: у нас уже были сформированы общие требования на позицию тимлида. Она называется «руководитель разработки юнита», или сокращенно TUL (от английского technical unit leader).

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

Предыстория

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

Кроссфункциональные команды

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

Фантастические тимлиды и где они обитают - 2

Требования к техническим лидерам

Каким требованиям должен соответствовать такой руководитель? Идеальный технический лидер:

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

Получается, наш TUL — это чуть больше, чем тимлид в обычном этом понимании. Можно спросить: «Неужели у всех ваших команд одинаковые требования для руководителей?». Конечно, нет. На требования также влияют профиль, то чем юнит занимается, его цели. Команды могут сильно отличаться по составу в зависимости от того, насколько велик функционал, за который они отвечают. Пара примеров на основе вакансий, которые у меня были.

Первый проект — это Domofond. Команда уже со старта должна была быть 12 человек, мы планировали перенести разработку Domofond из Южной Африки в Россию. Плюс мы должны были переписать проект с нынешнего стека технологий (.NET, Windows Server) на стек Авито, чтобы дальше можно было развивать и поддерживать его собственными силами. Мы хотели, чтобы руководитель этого юнита имел практический опыт руководства командой больше 10 человек. Он должен был уметь хорошо нанимать, и у него должен был быть опыт мобильной разработки, потому что у Domofond было два мобильных приложения, написанных на кроссплатформенном фреймворке Xamarin.

Фантастические тимлиды и где они обитают - 3

Вторая команда — это Verticals SWAT. Мы формировали её для того, чтобы поддержать тестирование бизнес-инициатив в вертикалях Авито (Авто и Недвижимость). Задача этой команды была в том, чтобы быстро делать маленькие прототипы, тестируя бизнес-гипотезы. У руководителя этой команды была задача выстроить процесс разработки так, чтобы мы эти бизнес-гипотезы могли быстро доставлять и тестировать. Он должен был хорошо понимать процесс запуска MVP и требования к нему.

Ищем кандидатов

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

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

Читаем резюме

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

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

И последнее, что даёт нам информацию — то, как сам кандидат пишет про себя, про свои навыки. Приведу примеры.

Фантастические тимлиды и где они обитают - 4

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

Фантастические тимлиды и где они обитают - 5

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

Фантастические тимлиды и где они обитают - 6

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

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

Проводим скрининг и запрашиваем рекомендации

Скрининг — это короткое интервью по телефону, где мы задаём всем кандидатам заранее подготовленные вопросы. По ответам мы хотим составить представление о человеке, получить недостающую информацию о нем. К сожалению, здесь никакими наработками поделиться не смогу, потому что светлая мысль о том, что скрининг-интервью можно проводить для тимлидов, мне пришла уже после того, как вакансии были закрыты. Но если бы я делал это сейчас, то я бы воспользовался советами из книги «Кто. Решите вашу проблему номер 1» Джеффа Смарта и Рэнди Стрит. Книга посвящена найму правильных людей и там есть отдельная глава, посвященная тому, как делать скрининг-интервью, а также большой раздел, посвященный формированию требований для вашей позиции.

Ещё один способ собрать недостающую информацию — рекомендации на кандидата. На этом этапе нет задачи собрать полноценный фидбэк от его коллег и начальника о том, как кандидат себя проявил. Это можно будет сделать в конце, когда мы уже поговорим с ним лично. Здесь это просто проверка на адекватность. Если говорить в терминах QA, то мы делаем smoke test и sanity check этого кандидата. Важная вещь: я делаю это не только для тех кандидатов, у которых профиль неполный, а вообще для всех, где я могу это сделать. Для этого я использую только свою сеть контактов, своих знакомых в этих компаниях, либо каких-то знакомых коллег. Это важно потому что иногда бывает, что кандидат вроде бы с хорошим профилем, всё здорово, но на него приходит негативный фидбэк, к которому стоит прислушаться.

Закончился второй этап. У нас должен появиться список кандидатов, с которыми мы хотим пообщаться. Переходим к самому интересному — к очному интервью.

Очное интервью

У нас в компании очные интервью на менеджерские позиции обычно состоят из трех этапов.

Первый этап очного интервью

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

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

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

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

Вопросы про технический бэкграунд

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

Вопросы про найм

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

Вопросы про управление людьми

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

Вопросы про разработку

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

Второй этап очного интервью

Закончили с первым этапом очного интервью. Если кандидат его проходит успешно, то второй этап очного интервью мы проводим с командой и стейкхолдерами. Обе мои вакансии были в продуктовые команды, а для тимлидов таких команд очень важно тесное взаимодействие с владельцем продукта (product owner) и бизнес-заказчиком. Поэтому состав участников был именно такой. При найме в другие команды этот этап может отличаться. Например, если это платформенный юнит и мы хотим, чтобы тимлид писал код, или если мы знаем, что команда не примет лидера, у которого технические скиллы хуже, чем у её участников, то здесь может проводиться глубокое техническое интервью, точно такое же, как делается для разработчиков.
Но у меня была продуктовая команда. Чем отличается первый этап очного интервью от второго? Во-первых, другой состав участников. На втором этапе вопросы могут пересекаться, с тем, что мы уже спрашивали кандидатов на первом этапе. Но поскольку их задают уже другие люди, с другим опытом, то мы получим другую точку зрения на этого кандидата. Коллеги могут увидеть что-то, чего не увидел я. Плюс для меня лично это был еще очень полезный этап в плане поддержания планки найма на нужном уровне, потому что когда поток кандидатов уменьшается, на интервью приходит все меньше и меньше людей, есть соблазн чуть-чуть понизить планочку и взять наконец хотя бы кого-нибудь, чтобы закрыть позицию. Но коллеги, которым придётся вместе с этим человеком работать, могут тебя вовремя остановить и сказать: «Подумай получше». И планка поднимается обратно.

Третий этап очного интервью

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

Фантастические тимлиды и где они обитают - 7

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

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

Фантастические тимлиды и где они обитают - 8

Это скриншоты реальной презентации, которую нам защищал кандидат проекта Domofond. Обычно на подготовку к ней нужно около двух недель. Презентация занимает 20-30 минут. Примерно столько же времени мы отводим на сессию вопросов и ответов.

Последний этап закончен. К этому моменту у нас должен появится кандидат, которому мы бы хотели сделать оффер. На этом можно было бы и закончить… Но есть еще один этап.
Иногда так бывает, что кандидат всем понравился, он очень классный, мы очень хотим видеть его у себя, но он по каким-то причинам сомневается, либо есть какие-то внешние обстоятельства, которые мешают ему принять решение. Например, он должен переехать из другого города, ему нужно перевозить семью, и это для него проблема. И здесь мы должны помочь ему принять правильное для нас решение. Я называю это «продать вакансию».
У меня был случай, когда все было классно, кандидат нам понравился, мы ему понравились, но он не мог определиться с датой выхода. Он говорил нам: «Я приду к вам через два-три месяца. Мне нужно доделать проект, над которым я работаю. Он очень важный, классный. Я не уверен, когда мы закончим». Мы позвали его в офис на последнюю финальную встречу, ответили на все вопросы, которые были у кандидата на тот момент неотвеченные, проговорили эту ситуацию, договорились о том, что он сможет в рабочее время помогать своей команде, у него будет возможность сдавать проект вместе с ними, в общем, мы всячески готовы были содействовать. Выдали ему оффер, договорились, что он придёт через месяц. Он оффер принял, вышел… и в итоге так и не воспользовался нашим предложением, потому что они сдали проект в срок.

Заключение

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

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

На этом всё. Спасибо за внимание. Если у вас появятся вопросы, пишите комментарии, я постараюсь на них ответить.

P.S. Эту тему я раскрывал в докладе на Saint TeamLead Conf 2018, вот слайды.
Для оформления использованы иконки под авторством Becris и Freepik на Flaticon.

Автор: GremniX

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js