Как я был тимлидом, а теперь — руководитель направления / Виталий Шароватов (Badoo)
•Download as PPTX, PDF•
0 likes•654 views
HighLoad++ 2017 Зал «Конгресс-Холл», 8 ноября, 11:00 Тезисы: http://www.highload.ru/2017/abstracts/3022.html В докладе я расскажу о двух темах: как выглядит рост из тимлида в руководителя отдела, и как выбирать тимлида себе на замену, помогать ему становиться эффективным. Выступление основано только на моем опыте работы с двумя командами: Mobile Web и Desktop Web. Возможно, вы уже читали мой пост на Хабре (https://habrahabr.ru/company/badoo/blog/326230/) о том, как из разработчика я вырос в тимлида, но это мое выступление будет чуть более высокого уровня. Я поделюсь моим обновленным опытом. ...
Recommended
Recommended
More Related Content
More from Ontico
More from Ontico (20)
Как я был тимлидом, а теперь — руководитель направления / Виталий Шароватов (Badoo)
- 1. Как я был тимлидом, а теперь руководитель отдела Виталий Шароватов
- 2. Кто я? — 80 лет в интернетах, 16 лет в IT — 2 команды, куча проектов — (m.)badoo.com, etc. — 2,5 года: разработчик — тимлид — руководитель направления — уже говорил о том, как вырос в тимлида
- 3. О чем я? — Почему нужны тимлиды, вообще? — Нанять или назначить? Вырастить! — Подбор -> Назначение -> Поддержка и контроль
- 4. Подбор #1 — для чего? — осознанный выбор — минимизация рисков провала — оцениваем инвестиции
- 5. Подбор #2 — когда? сразу! — запас времени на все стадии подбора и роста — заместитель — это прекрасно и необходимо — одна голова хорошо, а две — лучше
- 6. Подбор #3 — карточки — простой инструмент заведения информации — лучший анализ, формализация — ничего не забыто — мониторинг процесса развития — объективизация процесса
- 8. Подбор #4 — скоринг Скоринг нужных квалификаций и постоянное обновление оценок — бизнес-ориентированность; фокус на результат, а не процесс — коммуникации — уровень мотивации — успешные / неуспешные проекты (и почему) — уровень неформального лидерства
- 9. Подбор #5 — продажа — 1-1: ищем заинтересованных, продаём другим — 1-1 tip: обнажение инструментария — больше прозрачность и доверие команды
- 10. Подбор #6 — проекты — выявление людей с менеджерскими навыками — легкий подбор проекта и последующий анализ результатов — низкий риск провала
- 11. Подбор #7 — заместитель — эффективно передать = структурировать — легко мониторить, если присутствуешь — как адаптируется к незнакомой нагрузке? — как тщательно ведет рутину? — каков уровень неформального лидерства?
- 12. После подбора — сводим скоринг — подготавливаем команду
- 13. Назначение — объясняем команде, почему — формальная передача ответственности — работа с ожиданиями — флоу не меняется
- 14. Поддержка #1 — развиваем — менторство — коучинг — свободное плавание — всегда держим руку на пульсе!
- 15. Поддержка #2 — контролируем — постоянное подтверждение понимания — обнажение инструментария — больше времени на 1-1
- 16. Поддержка #3 — помогаем — умирающий тимлид — плохой тимлид — анализируем вместе время — обсуждаем приоритезацию задач — ставим “длинные” цели — прагматизм в решениях: зачем, сколько стоит, какие риски — рост — это выход из зоны комфорта
- 17. Результат — карточки и скоринг — начинаем подбирать сразу — подбор-назначение-поддержка-контроль — постоянная работа с рисками и ожиданиями
- 18. Спасибо! Всегда рад пообщаться на темы: — управление — мотивация — процессы email: v.sharovatov@corp.badoo.com
Editor's Notes
- Привет, меня зовут Виталий Шароватов, я уже 16 лет работаю в IT. Сейчас я управляю направлением фронтенд в Badoo. У меня две команды, занимающиеся разработкой и поддержкой десктопной версии сайта https://badoo.com и мобильной https://m.badoo.com плюс еще кучей разных проектов. Да, у нас отдельные команды делают отдельно мобильную и десктопную версию сайта :) Два с половиной года назад я пришел в Badoo в качестве разработчика, потом вырос до тимлида, а потом, когда было решено перевозить команду desktop web в лондон, и до руководителя направления. Прошлой осенью на Codemotion Milan я делал доклад о росте из разработчика в тимлида (и статья потом на хабре была) и том, какие неожиданные моменты были в том процессе для меня, а вот теперь расскажу про то, как при переходе из лида в руководителя отдела справился с подбором и выращиванием тимлида в одной команде (mobile web).
- Мне тимлиды нужны были по очень простой причине — для обеспечения управляемости командой из 25 человек и эффективности работы сотрудников при уменьшении “точек входа” в отделы. еще? Есть два варианта получения нового тимлида — нанять или назначить? Мы выбираем третий — вырастить. Во-первых, это часть культуры Баду — всегда помогать развиваться своим людям, во-вторых, по каждому разработчику уже есть хорошая история его работы. Почему это важно — расскажу дальше. Почему не “назначить”? Ну так, наверное, многие слышали или даже видели, как в тимлиды выбирают просто наиболее толкового инженера из всех, и чем это может быть чревато :) - - - - side story - - - - Лайтовая версия такой ситуации была за некоторое время до моего прихода — одному очень грамотному инженеру предложили поруководить небольшой командой, и какое-то время он ею вполне себе руководил, да вот только все труднее и труднее становилось с каждым днём, и демотивация росла и росла. Проблема была простой — человек был гипер-эмпатом, очень и очень трудно было ему в необходимых моментах использовать директивный подход, требовать с сотрудников жестко чего-то. В худшем случае подобный поход к выбору может привести к серьезной демотивации самого инженера (и хорошо, если получится обратно вернуться к инженерной работе!) — ведь с точки зрения человека, ему дали новую должность, а он не справился. Ощущение большого такого провала, кто-то с ним справится, кто-то нет. В той ситуации, о которой я рассказал, слава богу, все прошло удачно — разработчик был очень лояльным, и честно и вовремя сказал руководителю, что не получается, и что прямо ну совсем тяжко; а руководитель прислушался и забрал эту обязанность. Могло быть сильно хуже. - - - side story - - - - Я всегда считал, что лучше подходить к выбору и последующим шагам иначе, минимизируя все риски, и проводя последовательно серию действий, которую я обозначил как “подбор-назначение-поддержка и контроль”
- Осознанный выбор — минимизируем риск влияния личных ощущений на правильность выбора, действительно выбираем более подходящих. Все люди разные, и выбор тимлида должен основываться на определённых принципах, а не исходя из “ой, мне с ним так хорошо и комфортно болтать”. Минимизируем риски провала — не влияем негативно на мотивацию людей, как кандидатов, так и членов команды. Ну и, конечно, оцениваем объём инвестиций времени, что понадобится вложить в каждого кандидата. Если тимлид нужен бизнесу через месяц — разбираемся, какого кандидата взять — того, что почти подходит, но останется середнячком, или того, в которого нужно вложить много времени (возможно, и больше месяца), но который станет очень крепким?
- Как только вы стали тимлидом, нужно начинать подбирать себе “замену”. Это, вообще, хороший принцип — как только стал тимлидом, начинать планировать развитие своих подчиненных — создавая себе эту подушку безопасности по времени сразу. Но с заместителем-заменой история немного другая — это вообще, как мне кажется, одна из первых задач любого менеджера — поиск себе заместителя, работа отдела не имеет права останавливаться, если ты вдруг заболел, решил пойти в отпуск или уволиться :) Но для меня неожиданно приятным бонусом оказалось и то, что когда есть готовый “заместитель”, можно отдать ему отдел на время, самому погрузившись в какой-то важный проект с головой. Ну и, конечно же, при выращивании заместителя / будущего тимлида появляется еще один человек, с которым можно обыгрывать или обсуждать разные мысли.
- Что такое карточки для меня? Простой документ почти свободной (но однообразной для всех сотрудников формы), где описываются все ключевые для руководителя темы про сотрудника. Естественно, никому нельзя давать доступа к ним. Выгоды ведения карточек: 1. лучше анализируешь текущую ситуацию и более четко её формализуешь 2. уменьшаешь вероятность того, что какие-то моменты/истории/паттерны канут в лету 3. Упрощаешь анализ прогресса человека и мониторинг скорость развития. 4.“Объективируешь” процесс — более четко разделяешь свое личное отношение к человеку и его проф. качества и историю его работы и развития
- На слайд я поместил сильно сокращённую синтетическую версию карточки, многое пришлось опустить, но, думаю, понятна структура: качества с оценками, мотивация, роли, цели. Текущий уровень — наша система уровней отражена. Про оценки и скоринг я расскажу далее, пока просто смотрим на пример карточки Исходя из качеств и мотивации можем выводить цели, и работать по ним с сотрудником.
- Внутри карточек начинаешь делать “скоринг” кандидатов, и этот скоринг постоянно обновляешь с каждым новым заданием. Я не знаю, правильный ли термин “скоринг”, но я его для себя использую — подразумевая под ним постоянную переоценку качеств, важных для тимлида: Бизнес-ориентированность — насколько человек понимает и придерживается прагматизма, когда целью ставится результат для бизнеса, а не, скажем, уровень удовлетворённости от красоты и изящности кода. Тимлид должен в первую очередь руководствоваться принципами управления, а не личного комфорта. Простой пример — если бизнесу нужно провалидировать в рамках АБ-теста какую-то концепцию, весьма вероятно, что нет смысла делать покрытие кода тестовой группы юнит-тестами, даже если так “принято” покрывать тестами всё, и разработчику тесты писать “нравится”. коммуникации — в культуре Баду на коммуникациях построено очень многое, и умение эффективно общаться со всеми — серверниками, тестировщиками, топами, дизайнерами — просто необходимо. 3. уровень мотивации. На мой взгляд, тимлид должен обладать сильной внутренней мотивацией, ведь переход от разработчика к тимлиду — это переход не со ступеньки на ступеньку карьерной лестницы разработчика, а перепрыгивание на другую лестницу, стоящую наособицу — лестницу управления. Без сильной к тому мотивации любое развитие — а развитие суть выход из зоны кофморта — будет очень тяжелым. 4. история успешных/неуспешных проектов, туда же как-нибудь слинковываешь причины провалов проектов (чтобы потом проверять следующие проекты на наличие тех же паттернов провалов) и кратко описываешь их 5. уровень неформального лидерства, руководитель, умеющий за собой повести работников — сказать “ребята, к понедельнику нам очень нужно выложить вот такой функционал, кто со мной бросается на дзот?”, и чтобы ребята вызвались сами — эгегей, вперед! Также неформальное лидерство поможет тому, что команда более легко примет такого человека при назначении тимлидом.
- нужно понять, кто как заинтересуется управлением. я называю это “продажей”. Во время регулярных встреч — а у нас тимлиды их делают раз в две недели с каждым программистом — вентилировать вопрос заинтересованности человека другой карьерой — руководителя, показывать то, что делаешь сам и почему, смотреть, загораются ли глаза у человека. Задаешь вопросы — “слушай, Сильвестр, а ты видишь, что у Марио проблемы со сроками? Как думаешь, почему так? Как помочь человеку?” Смотришь, как реагирует человек, интересно ли ему попытаться разобраться в проблеме? Ответы чаще всего бывают двух типов — “чего ты мне менеджерские вопросы вообще задаешь, я сюда код писать пришел, можно я пойду дальше работать?”, и “ох блин, как интересно, наверное, Марк не смог у серверников стребовать сроков нормально, может, нам придумать какой-то другой формат планерок, чтобы эту проблему решить?” Сразу видно, что у человека загораются глаза, что он готов работать с людьми и тема эта ему интересна. Дополнительный вин — большая прозрачность в том, почему ты принимаешь определенные решения, увеличивающийся уровень доверия подчиненных. Ведь если они видят, что такие вопросы задаются — значит, руководитель о них думает, есть налаженный процесс.
- Проектная работа — работа над крупными и очень крупными задачами, в которых вовлечены много работников, отлично показывает уровень менеджерских навыков: как раз ту самую бизнес-ориентированность, нацеленность на результат, уровень коммуникации, умение планировать и требовать выполнения. Очень важно, что в проекте человеку неформально “подчиняются” другие разработчики, что Что еще удобно в проектной работе — легко подобрать “нужный” для текущей стадии проект: как людей (например, к эмпату можно подобрать “жесткого” человека и посмотреть, как эмпат с ним будет работать), так и с точки зрения сложности технической (может быть, проект-идея, в которой даже непонятно, в какую сторону “копать”, а результат нужен уже через неделю). Выгода — низкий риск провала. Для мотивации разработчика провалившийся проект — всего лишь эпизод, пусть и не самый приятный, но не влияющий кардинально на его мотивацию. Для мотивации других сотрудников, участвовавших даже в провальном проекте, все тоже не сильно плохо — “ну вот Серёга затупил, провалили проект”, а вовсе не “блин, и с этим редиско нам потом работать? нунет, лучше щас уволюсь”
- Как я уже говорил, заместителя искать придется все равно. Так что эту задачу придется решать так или иначе, но вот в качестве проверки кандидатов она очень хороша. 1 — Чтобы оставить заместителя, нужно ему эффективно передать свои рутинные действия, а для этого их нужно как-то их структурировать и документировать. 2 — Необязательно ждать своего отпуска, заместителю можно отдать свою работу на время — можно и заняться подготовкой к докладу, и одновременно помониторить работу зама :) Помимо стандартных метрик-качеств из карточки, становится о человеке понятно сразу очень многое: 1. насколько легко человек адаптируется к совершенно незнакомому типу нагрузки (а гибкость и скорость адаптации — один из ключевых навыков менеджера, как мне кажется), раскрыть дополнительно и примеры привести, ситуации и пример личный. Как организуется его работа личная 2. как тщательно ведет рутину — достаточно ли въедливости и внимательности для ее осуществления, или придётся вкладывать время в коучинг и в этой области — deputy-мотор, примеры, что такое наша статистика (для контекста) 3. Какой уровень неформального лидерства в команде — отличается ли то, как работает человек будучи deputy от того, как он работал на проектной работе. Видно, как воспринимают его люди.
- Что делаем после применения инструментов подбора? 1 — Осталось какое-то число кандидатов, сведением их скоринга удается выделить одного. Оценили риски, оценили объём инвестиций времени. По сути, мы готовы назначать тимлида уже сейчас. 2 — спрашиваем на регулярных 1-1, как им работалось с этим товарищем в роли ведущего проект или заместителя, подготавливаем их к назначению, убираем потенциальные ожидания и обиды. Вдруг кто-то еще думал, что станет тимлидом (ведь подготовительные действия могут быть видны людям, особенно тем, кто также был кандидатом)
- Поработав с ожиданиями на предыдущем шаге, я уже готов к назначению тимлида. На очередной еженедельной встрече с командой официально назначаю тимлида, рассказываю, почему я остановил выбор на этом человеке. Озвучиваю официально, что все вопросы теперь решаются этим человеком в первую очередь. Работаю с ожиданиями — тщательно проговариваю, что я никуда не денусь и буду мониторить все, что происходит, помогать во всех вопросах поначалу. Опять же — рассказываю, что никаких резких изменений не будет. Минимизирую количество “изменений” в жизни людей. Рассказываю, что поначалу буду очень вовлечен во всех процессах.
- После назначения тимлиду будет необходима помощь. Считаю правильным применять классическое ситуационное управление по всем стадиям, подразумевая низкую профессиональную квалификацию (ведь человек не занимался еще этим на постоянной основе) и высокую мотивацию (иначе, чем с высокой мотивацией к такому изменению было бы выбирать кандидата очень сомнительно :)) 1— сначала “ведём за ручку”, практически директивный подход, менторим нового тимлида, говорим ему: “делай как я” и объясняем почему и отчего. 2 — Затем переходим к коучингу, спрашивая “как бы сделал ты и почему”, постоянные консультации. 3 — Затем уже свободное плавание — либеральный подход “мне нужны вот такие результаты, делай пожалуйста” и всегда держим руку на пульсе и регулярно помогаем тимлиду, о чем на следующем слайде
- Неверные действия тимлида могут стоить гораздо дороже, чем неверные действия разработчика. Просто необходимо намного тщательнее прорабатывать все моменты, удостоверяясь, что даже малейшей неясности в коммуникации с тимлидом нет (если у разработчиков небольшие непонимания “выравниваются” друг об друга, то тимлид над командой один) Контролируем четко тут именно стратегию — более высокие точки контроля, не смотрим в каждый байт его решений, и даже ошибку пусть совершит Что делаем? 1 — На встречах с тимлидом при обсуждении любых вопросов постоянно проверяем: “расскажи мне, как ты понял”, “расскажи своими словами” и проч. 2 — постоянно “обнажаем инструментарий” — смотри, я тебя подвёл к решению какого-то вопроса наводящими вопросами, но решил его ты сам. Видишь, как мой коучинг работает на тебе — он так же сработает на ребятах. Добавить пример личный 2 — Отсюда следует, что необходимо выделять значительно бОльшее время на 1-1 с лидом, чем раньше тратил на 1-1 с каждым разработчиками. У меня как минимум полтора часа в неделю постоянного общения с тимлидами, и еще куча небольших синхронизационных “перекуров”
- Подразумевая, что тимлид обладает высокой мотивацией, есть немаленькая такая вероятность, что человек будет пытаться быть максимально эффективным, и для этого начнет перерабатывать. Необходим контроль выгорания — не перестаешь требовать больше, но просишь анализ проводимого времени 2 — я делал сам себе простой анализ времени — 15-20 минутные слоты записывал в течение дня, “тэгировал” их, а потом раз в неделю садился и анализировал, а на что, собственно, время ушло. 3 — обсуждаешь приоритезацию задач, смотришь, что срочно, что важно, а что срочно и важно. Матрица эйзенхауэра во всей красе. Доносишь, что ничего “плохого” нет в том, что чего-то тимлид не знает или не успевает: “мы все с чего-то начинали”, важно проанализировать расход ограниченных ресурсов (времени) и подходить к его трате рационально. Зачем сидим допоздна? Сидеть допоздна реально нужно очень редко. 4 — ставим более стратегические цели, чем перед разработчиков. Постоянно приучаем к более длинному горизонту планирования. 5 — цена неразумной траты времени командой в случае нерационально принятого тимлидом решения — довольно высока. Постоянно проповедуем тимлиду, что наше кредо — прагматизм. Любые решения должны отвечать на вопросы “зачем”, “сколько стоит” и “какие риски”. 6 — проповедуем, что мягкость приводит к тому, что сядут на шею “довольные люди”, а последовательность в развитии людей приводит к удовольствию от результатов и роста
- Эти простые инструменты и подходы дали мне возможность получить успешного тимлида в команду Mobile Web, и, надеюсь, помогут и вам. Итак, снова хочу выделить самое основное, на мой взгляд
- Эти простые инструменты и подходы дали мне возможность получить успешного тимлида в команду Mobile Web, и, надеюсь, помогут и вам. Итак, снова хочу выделить самое основное, на мой взгляд