Фантастические тимлиды и где они обитают
Всем привет! Меня зовут Анатолий Панов, я работаю в ИТ уже больше 15 лет. За это время прошел путь от разработчика до руководителя тимлидов. Работал в таких компаниях как Badoo, Lazada. С начала этого года я в Авито. Руковожу разработкой новых проектов и разработкой для вертикалей Авто и Недвижимость.
В начале работы в Авито передо мной стояла задача собрать три команды разработки. Две из них были уже частично укомплектованы разработчиками, но ни в одной из них не было технического руководителя. Их нужно было быстро найти и нанять.
Как оказалось, это не так уж и просто. Помимо базового требования к техлидам — быть хорошими разработчиками, они должны быть еще и хорошими менеджерами, найти которых ещё сложнее. Программированию можно научиться, сидя дома за компьютером, а чтобы стать хорошим тимлидом, обязательно нужна практика с живыми людьми. Найти себе тестовую команду представляется проблематичным.
Сегодня я хотел бы поделиться своим опытом поиска и найма тимлидов. Расскажу, с чего стоит начать, и к какому процессу проведения интервью я пришел.
Первая мысль, конечно же, была такой: давайте запромоутим внутреннего кандидата. Но начавшаяся 1,5 года назад трансформация из функциональных команд в кроссфункциональные уже «съела» весь резерв. Только одну позицию удалось закрыть изнутри, еще двух человек предстояло нанять.
До этого мне не приходилось заниматься наймом тимлидов. У меня в командах они появлялись более традиционным способом: всегда были ребята, которые показывали себя хорошо в деле, и мы повышали их.
Оказалось, что процесс найма тимлидов состоит из тех же трех больших этапов, что и найм разработчиков.
- Составить требование, профиль кандидата.
- Найти кандидатов на рынке, понять, кто из них подходит к профилю.
- Провести очное интервью.
Я пройдусь по всем трем этапам и расскажу, что я делал на каждом из них, чтобы найти подходящего кандидата.
Чтобы запустить поиск кандидатов на вакансию, у нас должен появиться профиль кандидата, документ, в котором написано, что за позиция, кого мы на нее ищем, цели кандидата, которые будут стоять перед ним в ближайшее время, и навыки, которыми он будет обладать.
Мне повезло: у нас уже были сформированы общие требования на позицию тимлида. Она называется «руководитель разработки юнита», или сокращенно TUL (от английского technical unit leader).
Прежде чем поговорим подробнее про требования, я бы хотел рассказать немножко о том, как у нас устроена разработка, чтобы было понятно, почему сложились определённые требования.
Предыстория
Мы начинали с обычной функциональной структуры. В Авито были группы разработки бэкенда, фронтенда, мобильные разработчики, тестировщики. Всё стандартно. Когда нужно было сделать какую-то большую задачу, она либо декомпозировалась, и маленькие кусочки спускались внутрь команд и приоритезировались внутри, либо под задачу собирались кроссфункциональные команды. Со временем это перестало работать. Всё сложнее становилось приоритезировать, команд становилось больше, было много коммуникации между ними. Задачи перестали долетать до продакшна с нужной нам скоростью.
Кроссфункциональные команды
Мы решили перейти к кроссфункциональным командам. Мы называем их юнитами. Они образуются у нас вокруг значимых частей бизнес-функциональности. Например: мессенджер, подача объявлений, поисковая выдача, сам движок поиска. Юнит содержит в себе все компетенции для того, чтобы дотащить фичу от этапа идеи до продакшна с минимальными зависимостями от внешних команд. В него входят и технические функции, и продуктовая в виде менеджеров продукта, дизайнеров — всех тех людей, которые нам подготавливают бэклог.
У каждого юнита есть два типа руководителей. Первый — юнит лидер, его задача заключается в том, чтобы сформировать бэклог для команды и приоритезировать его. Он отвечает за достижение бизнес-целей. Второй — это как раз-таки технический руководитель юнита. Он отвечает за то, что делает команда разработки, за качество кода, который они пишут, за его безопасность, за планирование и достижение целей. Участвует в формировании продуктового бэклога (его задача заключается в том, чтобы найти технические блокеры и заранее позаботиться об их устранении).
Требования к техническим лидерам
Каким требованиям должен соответствовать такой руководитель? Идеальный технический лидер:
- имеет технический бэкграунд,
- умеет управлять людьми,
- умеет нанимать правильных людей,
- имеет понимание, как строить процесс разработки,
- знает, как развивать себя и команду,
- ориентирован на бизнес-результат,
- умеет планировать и контролировать достижение результата.
Получается, наш TUL — это чуть больше, чем тимлид в обычном этом понимании. Можно спросить: «Неужели у всех ваших команд одинаковые требования для руководителей?». Конечно, нет. На требования также влияют профиль, то чем юнит занимается, его цели. Команды могут сильно отличаться по составу в зависимости от того, насколько велик функционал, за который они отвечают. Пара примеров на основе вакансий, которые у меня были.
Первый проект — это Domofond. Команда уже со старта должна была быть 12 человек, мы планировали перенести разработку Domofond из Южной Африки в Россию. Плюс мы должны были переписать проект с нынешнего стека технологий (.NET, Windows Server) на стек Авито, чтобы дальше можно было развивать и поддерживать его собственными силами. Мы хотели, чтобы руководитель этого юнита имел практический опыт руководства командой больше 10 человек. Он должен был уметь хорошо нанимать, и у него должен был быть опыт мобильной разработки, потому что у Domofond было два мобильных приложения, написанных на кроссплатформенном фреймворке Xamarin.
Вторая команда — это Verticals SWAT. Мы формировали её для того, чтобы поддержать тестирование бизнес-инициатив в вертикалях Авито (Авто и Недвижимость). Задача этой команды была в том, чтобы быстро делать маленькие прототипы, тестируя бизнес-гипотезы. У руководителя этой команды была задача выстроить процесс разработки так, чтобы мы эти бизнес-гипотезы могли быстро доставлять и тестировать. Он должен был хорошо понимать процесс запуска MVP и требования к нему.
Итак, первый этап закончился. У нас есть профиль кандидата, с которым можно идти в HR: рассказать им, что мы хотим, сидеть и с радостью ждать, когда нам принесут кучу классных резюме.
Всё здорово? Нет. Резюме редко показывает реальные возможности кандидата, его навыки, что он умеет делать. Я наблюдал такое очень часто: по резюме кажется, что это классный специалист, но на интервью ты понимаешь, что это ошибочное впечатление. Поэтому на этапе поиска резюме мы просто определяем, хотим ли мы с этим человеком общаться лично или нет. Подходит он нам по профилю (который сформирован на прошлом этапе), или нет.
Читаем резюме
На что я смотрю в резюме?
Самое очевидное — опыт работы. Я смотрел кандидатов от года: считаю, что это тот срок, когда человек может набить достаточное количество менеджерских шишек и вжиться в эту роль, если он никогда этим не занимался.
Очень часто бывает так, что HR приносит «пустое» резюме: там только список компаний, в которых человек работал, и должности. Обычно такое бывает, потому что человек активно не ищет работу, его нашли где-то на LinkedIn. Либо приносят резюме, похожее на наш профиль кандидата, но в нём информация, которая ничего о человеке конкретного не говорит. «Я занимался разработкой микросервисов», «я делал сервис такой-то». Но если компания, в которой работал кандидат, довольно известная, то косвенно о его навыках можно судить по публичной информации о компании.
И последнее, что даёт нам информацию — то, как сам кандидат пишет про себя, про свои навыки. Приведу примеры.
Первый кандидат пишет, что он занимался проектированием новой схемы шардинга, внедрением мониторинга, оптимизацией основной БД проекта, перезапуском проекта на новой платформе. Очень много про технологии и мало про процессы. Видимо, это хороший технарь, но нам не понятно, умеет ли он управлять командой.
Второй кандидат пишет, что занимался анализом бизнес-требований, подготовкой конкурсной документации, сопровождением производственного процесса. Ничего про технологии, ничего про команду, всё про процессы. Скорее всего это, хороший менеджер.
Третий кандидат занимался управлением командой, делал технический анализ архитектуры, исправлял ошибки, разработкой занимался, играющий тренер, набирал людей в команду. Достаточно сбалансированное резюме. Выглядит так, как будто все те навыки, которые нас интересуют, у него есть. С таким человеком я бы хотел пообщаться лично.
После такого анализа у нас должно появиться несколько человек, которые имеют много совпадений с профилем нашего кандидата. Но иногда есть люди, по резюме которых кажется, что они нам должны подойти, но мы все еще не понимаем, хотим мы их позвать или нет — недостаточно информации. Есть ещё два способа, откуда её можно взять.
Проводим скрининг и запрашиваем рекомендации
Скрининг — это короткое интервью по телефону, где мы задаём всем кандидатам заранее подготовленные вопросы. По ответам мы хотим составить представление о человеке, получить недостающую информацию о нем. К сожалению, здесь никакими наработками поделиться не смогу, потому что светлая мысль о том, что скрининг-интервью можно проводить для тимлидов, мне пришла уже после того, как вакансии были закрыты. Но если бы я делал это сейчас, то я бы воспользовался советами из книги «Кто. Решите вашу проблему номер 1» Джеффа Смарта и Рэнди Стрит. Книга посвящена найму правильных людей и там есть отдельная глава, посвященная тому, как делать скрининг-интервью, а также большой раздел, посвященный формированию требований для вашей позиции.
Ещё один способ собрать недостающую информацию — рекомендации на кандидата. На этом этапе нет задачи собрать полноценный фидбэк от его коллег и начальника о том, как кандидат себя проявил. Это можно будет сделать в конце, когда мы уже поговорим с ним лично. Здесь это просто проверка на адекватность. Если говорить в терминах QA, то мы делаем smoke test и sanity check этого кандидата. Важная вещь: я делаю это не только для тех кандидатов, у которых профиль неполный, а вообще для всех, где я могу это сделать. Для этого я использую только свою сеть контактов, своих знакомых в этих компаниях, либо каких-то знакомых коллег. Это важно потому что иногда бывает, что кандидат вроде бы с хорошим профилем, всё здорово, но на него приходит негативный фидбэк, к которому стоит прислушаться.
Закончился второй этап. У нас должен появиться список кандидатов, с которыми мы хотим пообщаться. Переходим к самому интересному — к очному интервью.
У нас в компании очные интервью на менеджерские позиции обычно состоят из трех этапов.
Первый этап очного интервью
Первый этап — это самое обычное интервью с руководителем и HR. Задача этого этапа — понять, соответствует ли профиль кандидата тому, что нам нужно.
Если сравнивать найм разработчика и тимлида, то у разработчика его хардскиллы очень легко проверяются экзаменационным интервью. Глядя, как кандидат отвечает на вопросы, как он решает задачи, мы можем судить о его знаниях. Важно то, что если кандидат знает, как что-либо делать, скорее всего, он будет применять это в своей работе. С тимлидами все по-другому. У них очень часто хардскиллы являются софтскиллами. Например, умение давать обратную связь — это хардскилл для тимлида, но сам скилл — это софтскилл. Проверить такие умения на интервью очень тяжело.
Мы можем спросить кандидата: «Умеешь ли ты давать обратную связь?», и он, конечно, ответит: «Да, умею». Мы можем попробовать с ним проиграть ролевую сценку, попросить его дать нам обратную связь, но все понимают, что мы находимся на интервью, и кандидат, скорее всего, будет давать нам какой-то социально ожидаемый ответ. Мы никогда не узнаем, будет ли он поступать так же в реальной жизни. Поэтому для менеджерских позиций важнее всего смотреть не на теоретические знания, которые есть у кандидата, а на его реальный практический опыт. То, чем он занимался, какие проблемы он решал, с чем он сталкивался, как он преодолевал трудности.
Теоретические вопросы тоже можно задавать, но только в том случае, если по каким-то причинам у кандидата не было реального опыта решения задач из этой области. Например, он никогда не нанимал людей, у него был большой HR-департамент, который все делал за него.
Приведу несколько примеров того, что спрашиваю я на собеседования, и расскажу, что мы проверяем этим.
Вопросы про технический бэкграунд
Первый блок — это вопросы про технический бэкграунд кандидата. Я начинаю с того, что прошу рассказать о какой-то интересной фиче, проекте, о чем-то, чем кандидат занимался. Дальше в зависимости от ответов можно углубляться в детали. Можно спросить о том, какова была архитектура проекта, чтобы кандидат нам рассказал, порисовал на доске. Это нужно чтобы посмотреть, как он умеет рассказывать о чем-то сложном человеку, который не знаком с этой областью знаний. Можно поговорить с ним про нагрузку, если его проект был высоконагруженным, и нас интересует эта тема. Если кандидат рассказывает о том, что это была просто интересная продуктовая фича, которая была классной с точки зрения продукта, можно целенаправленно спросить: «Какие сложные технические проекты вы делали?».
Вопросы про найм
Следующий блок — вопросы, связанные с наймом. Доводилось ли человеку заниматься подбором? Если да, то как выглядел процесс? Какие вопросы он задаёт на собеседованиях? Как он проверяет те или иные качества у кандидатов, на что он вообще смотрит, каких людей он хочет нанимать себе в команду?
Вопросы про управление людьми
Третий блок вопросов — про управление людьми. Мой любимый звучит так: «Приходилось ли вам увольнять сотрудников?». Он классный, потому что это тяжелая и болезненная история для всех участников этого процесса: и для самого тимлида, и для человека, которого он увольняет. И если тимлид уже проходил через это, то это отличный показатель его опыта. Плюс, скорее всего, в этой истории можно будет еще покопаться, потому что увольнение вполне может быть недоработкой самого тимлида.
Вопросы про разработку
Следующий блок — про разработку. Я спрашиваю про то, как был устроен процесс в его команде, делал ли он его сам, либо процесс был поставлен кем-то сверху. Соответственно, если сам процесс он не делал, то понимает ли он, почему процесс выглядел именно так. Ну, а если что-то в процессе разработки кандидата не устраивало, то стоит спросить, пытался ли он что-то изменить.
Второй этап очного интервью
Закончили с первым этапом очного интервью. Если кандидат его проходит успешно, то второй этап очного интервью мы проводим с командой и стейкхолдерами. Обе мои вакансии были в продуктовые команды, а для тимлидов таких команд очень важно тесное взаимодействие с владельцем продукта (product owner) и бизнес-заказчиком. Поэтому состав участников был именно такой. При найме в другие команды этот этап может отличаться. Например, если это платформенный юнит и мы хотим, чтобы тимлид писал код, или если мы знаем, что команда не примет лидера, у которого технические скиллы хуже, чем у её участников, то здесь может проводиться глубокое техническое интервью, точно такое же, как делается для разработчиков.
Но у меня была продуктовая команда. Чем отличается первый этап очного интервью от второго? Во-первых, другой состав участников. На втором этапе вопросы могут пересекаться, с тем, что мы уже спрашивали кандидатов на первом этапе. Но поскольку их задают уже другие люди, с другим опытом, то мы получим другую точку зрения на этого кандидата. Коллеги могут увидеть что-то, чего не увидел я. Плюс для меня лично это был еще очень полезный этап в плане поддержания планки найма на нужном уровне, потому что когда поток кандидатов уменьшается, на интервью приходит все меньше и меньше людей, есть соблазн чуть-чуть понизить планочку и взять наконец хотя бы кого-нибудь, чтобы закрыть позицию. Но коллеги, которым придётся вместе с этим человеком работать, могут тебя вовремя остановить и сказать: «Подумай получше». И планка поднимается обратно.
Третий этап очного интервью
Последний этап — это защита кейса. Это такое тестовое задание для менеджеров. Идея ровно такая же как с тестовым заданием для разработчиков: проверить, как кандидат будет себя вести в реальной ситуации. Здесь очень важно давать пример, максимально приближенный к тому, какая ситуация сложилась у вас в команде, потому что только тогда вы сможете понять, как же кандидат будет себя вести, если он к вам придет работать. Как выглядел кейс у меня? Покажу на примере проекта Domofond.
Основная часть — это текущее описание ситуации в команде, состав, технологии, навыки, проекты, которые сейчас в работе, цели и планы на ближайшее будущее для команды и кандидата. И какие-то ограничения, если они есть.
Основные вещи, которые кандидат должен был осветить в нашем кейсе — это предложить вариант переноса проекта на стек технологий Авито, аргументировать, почему было выбрано именно такое решение. Представить roadmap переноса и план на первые 100 дней работы.
Ключевые критерии успеха были такими. Перенос нужно было закончить в течение шести месяцев, максимально использовать инфраструктурные платформенные технологии Авито. Проект должен был остаться в рамках бюджета. И миграция должна была пройти с фича-фризом длиной в максимум один спринт.
Это скриншоты реальной презентации, которую нам защищал кандидат проекта Domofond. Обычно на подготовку к ней нужно около двух недель. Презентация занимает 20–30 минут. Примерно столько же времени мы отводим на сессию вопросов и ответов.
Последний этап закончен. К этому моменту у нас должен появится кандидат, которому мы бы хотели сделать оффер. На этом можно было бы и закончить… Но есть еще один этап.
Иногда так бывает, что кандидат всем понравился, он очень классный, мы очень хотим видеть его у себя, но он по каким-то причинам сомневается, либо есть какие-то внешние обстоятельства, которые мешают ему принять решение. Например, он должен переехать из другого города, ему нужно перевозить семью, и это для него проблема. И здесь мы должны помочь ему принять правильное для нас решение. Я называю это «продать вакансию».
У меня был случай, когда все было классно, кандидат нам понравился, мы ему понравились, но он не мог определиться с датой выхода. Он говорил нам: «Я приду к вам через два-три месяца. Мне нужно доделать проект, над которым я работаю. Он очень важный, классный. Я не уверен, когда мы закончим». Мы позвали его в офис на последнюю финальную встречу, ответили на все вопросы, которые были у кандидата на тот момент неотвеченные, проговорили эту ситуацию, договорились о том, что он сможет в рабочее время помогать своей команде, у него будет возможность сдавать проект вместе с ними, в общем, мы всячески готовы были содействовать. Выдали ему оффер, договорились, что он придёт через месяц. Он оффер принял, вышел… и в итоге так и не воспользовался нашим предложением, потому что они сдали проект в срок.
В заключение я бы хотел подчеркнуть то, что я вынес для себя из этого опыта интересного и полезного.
- Во-первых, если у вас есть желание и возможности учить и растить кандидата, то лучше всегда это делать изнутри. История с внутренним карьерным ростом всегда лучше, чем вы будете постоянно нанимать тимлидов.
- Во-вторых, надо обязательно делать скрининг-интервью по телефону. Эта штука поможет сократить количество кандидатов, которых вы зовете на очное интервью, и которые вам явно не подходят.
- В-третьих, для менеджерских позиций интервью на основе опыта — гораздо лучше и полезнее, чем теоретическое интервью. Про опыт сложнее соврать, он лучше показывает то, как кандидат будет вести себя в подобных ситуациях в будущем.
- В-четвёртых, лично для меня защита кейса оказалась новым и крайне полезным инструментом. Я знал, что такие штуки делают для кандидатов на менеджерские позиции в нетехнические области, но для ИТ-специалистов я делал это впервые, и инструмент оказался очень полезен. Он может помочь кандидату раскрыть себя, подробно рассказать, как он видит свою работу в будущем. Именно защита кейса стала решающей в выборе будущего коллеги, потому что его рассказ максимально точно совпал с тем, что мы ожидали. И мы сделали ему оффер.
На этом всё. Спасибо за внимание. Если у вас появятся вопросы, пишите комментарии, я постараюсь на них ответить.
P.S. Эту тему я раскрывал в докладе на Saint TeamLead Conf 2018, вот слайды.
Для оформления использованы иконки под авторством Becris и Freepik на Flaticon.
