Предыстория

Привет! Меня зовут Виталий Шароватов, я уже 16 лет работаю в IT. Сейчас я руковожу направлением фронтенд в Badoo. В него входят две команды, которые занимаются разработкой и поддержкой десктопной версии сайта badoo.com, мобильной версии m.badoo.com и многими другими проектами. Да, десктопную и мобильную версии у нас делают отдельные команды. :)

Два с половиной года назад я пришел в Badoo разработчиком, со временем вырос до тимлида, а потом, когда было решено перевозить команду Desktop Web в Лондон, стал руководителем направления.

Прошлой осенью на Codemotion Milan я делал доклад о росте из разработчика в тимлида (и писал на Хабр статью об этом) и о том, с какими неожиданными моментами мне пришлось столкнуться, а теперь расскажу, как при переходе из лида в руководителя направления я справился с подбором и «выращиванием» тимлида в одной из команд (Mobile Web).

Зачем вообще нужны лиды и откуда их брать?

Мне тимлиды нужны были по очень простым причинам — для обеспечения управляемости командой из 25 человек и поддержания эффективности работы сотрудников при уменьшении количества «точек входа» в отделы.

Есть два классических варианта получения нового тимлида: нанять или назначить. Но мы выбираем третий — «вырастить». Во-первых, это часть культуры Badoo — всегда помогать развиваться своим людям; во-вторых, у каждого разработчика есть хорошая история его работы (о том, почему это важно, расскажу ниже).

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

Лайтовая версия такого сценария произошла в Badoo за некоторое время до моего прихода в компанию: одному очень грамотному инженеру предложили поруководить небольшой командой, и какое-то время он ею вполне неплохо руководил, вот только с каждым днём становилось всё труднее и труднее, и демотивация росла и росла. Проблема была простой: человек не хотел никого обидеть или показаться слишком резким. Поэтому в ситуациях, в которых требовалось применение директивного подхода, у него совсем не получалось жёстко требовать чего-то от сотрудников. В худшем случае такая ошибка с выбором может привести к серьёзной демотивации самого инженера (и хорошо, если у него получится вернуться к инженерной работе!) — ведь по мнению человека, ему доверили новую должность, а он не справился. К счастью, в той ситуации всё закончилось хорошо: разработчик был очень лоялен компании и честно вовремя сказал руководителю, что у него не получается, а руководитель, в свою очередь, прислушался и снял с него эту «непосильную ношу». Могло быть значительно хуже.

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

Подбор: как?

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

Минимизируем риск провала — не влияем негативно на мотивацию людей (как кандидатов, так и других членов команды).

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

Подбор: когда?

Как только вы стали тимлидом, нужно начинать подбирать себе замену.

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

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

Но для меня неожиданно приятным бонусом оказалось то, что, когда есть готовый «заместитель», можно на время поручить ему руководство отделом, а самому погрузиться в какой-то важный проект.

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

Подбор: карточки

Что такое карточки для меня? Простой документ почти свободной (но единообразной для всех) формы, где описываются все ключевые для руководителя вещи про сотрудника. Естественно, никому нельзя давать доступ к ним.

Преимущества ведения карточек:

1. Более глубокий анализ текущей ситуации и более чёткая её формализация.
2. Уменьшение вероятности того, что какие-то моменты/ истории/ паттерны канут в лету.
3. Упрощение анализа прогресса человека и мониторинг скорости его развития.
4. «Объективация» процесса — более чёткое разделение своего личного отношения к человеку и его профессиональных качеств, истории его работы и развития.

Это сокращённая версия карточки, многое пришлось опустить, но, думаю, структура понятна: качества с оценками, мотивация, роли, цели.

Кратко опишу структуру карточки:

• current level — текущая ступень развития сотрудника в компании. В Badoo действует система уровней, схожая с системой Google; в вашей компании может быть совсем другая «лестница» (например, на заводах приняты разряды);
• plan — моё видение плана развития сотрудника;
• qualities — произвольно оцениваемые (моя шкала — от одного до пяти) навыки и качества сотрудника (для наглядности я считаю крайне важным указывать подтверждающие оценку рабочие события);
• motivation — мои представления о мотивации сотрудника. Каждый раз, когда я пересматриваю или обновляю карточки, я стараюсь заново оценивать мотивацию. На мой взгляд, это вообще один из самых важных пунктов карточки, потому что для выстраивания планов по развитию сотрудника просто необходимо оценивать его мотивацию;
• roles — текущие или планируемые роли сотрудника в команде;
• goals — поставленные перед сотрудником (или мной) цели, исходя из его мотивации, проблем/успехов и бизнес-целей команды.

Про оценки и скоринг я расскажу ниже.

Подбор: скоринг

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

• Бизнес-ориентированность — насколько человек прагматичен, когда целью является результат для бизнеса, а не, скажем, уровень удовлетворённости красотой и изящностью кода. Тимлид должен в первую очередь руководствоваться принципами управления, а не личного комфорта. Простой пример: если бизнесу нужно провалидировать в рамках A/B-теста какую-то концепцию, вероятно, нет смысла делать покрытие кода тестовой группы юнит-тестами, даже если принято покрывать тестами всё, и разработчику нравится писать тесты.
• Коммуникации. В культуре Badoo на коммуникациях построено очень многое, и умение эффективно общаться со всеми — серверниками, тестировщиками, топами, дизайнерами — просто необходимо.
• Уровень мотивации. На мой взгляд, тимлид должен обладать сильной внутренней мотивацией, ведь превращение из разработчика в тимлида — это не переход со ступеньки на ступеньку карьерной лестницы, а перепрыгивание на другую лестницу, стоящую особняком, — лестницу управления. Без сильной мотивации любое развитие — а развитие всегда есть выход из зоны комфорта — будет очень тяжёлым.
• История удачных/неудачных проектов. Сюда же относятся причины провалов проектов (чтобы потом проверять следующие проекты на наличие тех же паттернов провалов).
• Уровень неформального лидерства. Руководитель должен уметь вести за собой сотрудников, мотивировать их на достижение целей. Кроме того, неформального лидера команда легче примет в качестве тимлида.

Подбор: продажа

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

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

Например, можно задать вопросы из серии «Сильвестр, а ты видишь, что у Марио проблемы со сроками? Как думаешь, почему так? Как помочь человеку?» и смотреть, как человек реагирует, интересно ли ему попытаться разобраться в проблеме.

Ответы бывают двух типов: «Чего ты мне менеджерские вопросы задаёшь?! Я сюда код писать пришёл. Можно я пойду дальше работать?», и «Ох, блин, как интересно! Наверное, Марио не смог у серверников истребовать сроки нормально. Может, нам придумать какой-то другой формат планёрок, чтобы эту проблему решить?» Сразу видно, что во втором случае у человека горят глаза, что он готов работать с людьми, и работа эта ему интересна.

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

Подбор: проекты

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

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

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

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

Подбор: заместитель

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

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

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

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

После подбора

Что делать после успешного применения инструментов подбора?

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

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

Назначение

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

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

Поддержка: развитие

После назначения новоиспечённому тимлиду будет необходима помощь.

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

1. Сначала тимлида придётся «вести за ручку», используя практически директивный подход, говорить ему: «Делай, как я» и объяснять, почему.
2. Затем можно переходить к коучингу, спрашивая: «Как бы сделал ты и почему?» и консультировать по всем вопросам.
3. После этого уже можно отпустить тимлида в свободное плавание и перейти на либеральный подход «Мне нужны вот такие результаты; делай, пожалуйста».

Конечно, всегда нужно держать руку на пульсе и регулярно помогать тимлиду.

Поддержка: контроль

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

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

Что делать?

1. На встречах с тимлидом при обсуждении любых вопросов постоянно проверять его понимание сказанного: «Расскажи мне, как ты понял», «Объясни своими словами» и т. д.
2. Постоянно «обнажать инструментарий»: «Смотри, я тебя подвёл к решению задачи наводящими вопросами, но решил её ты сам. Видишь, как мой коучинг работает на тебе — он так же сработает на ребятах». Хорошо бы добавить личный пример.
3. Выделять больше времени на встречи с лидом, чем раньше тратилось на общение с каждым разработчиком. У меня на общение с тимлидами уходит как минимум полтора часа в неделю, плюс куча небольших синхронизационных обсуждений.

Поддержка: помощь

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

Необходим контроль выгорания: не требовать меньше, а просить делать анализ затрачиваемого времени. Я делал это так: в течение дня записывал 15—20-тиминутные слоты, «тегировал» их, а потом раз в неделю садился и анализировал, на что, собственно, уходит моё время.

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

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

Цена неразумной траты времени командой в случае ошибочного решения тимлида довольно высока. По этой причине постоянно напоминаем тимлиду, что наше кредо — прагматизм, и любое решение должно отвечать на вопросы «Зачем?», «Сколько стоит?» и «Какие риски?»

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

Выводы и результаты

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

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

1. Не стоит тянуть с подбором тимлида: чем раньше начнёте, тем больше вероятность успеха.
2. Карточки и скоринг — необходимые инструменты для объективного выбора.
3. Подбор, назначение, поддержка и контроль — неизбежные и обязательные этапы, которые помогают достичь эффективного взаимодействия не только руководителя с тимлидом, но и тимлида и руководителя со всей командой.
4. Работать с рисками и ожиданиями нужно регулярно, а не только когда что-то идёт не так. Это кажется очевидным, и всё же нужно постоянно напоминать себе об этом.

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