На пути от традиционной иерархии developer – teamlead – CTO до загадочного Servant Leadership в booking.com проходили и автономию. Отличная идея, дать людям свободу, возможность развиваться, расти, самим достигать цели, должна была замотивировать сотрудников.
Георгий Могелашвили (glamcoder) на TeamLead Conf рассказал обо всех этапах, и в том числе о том, что нельзя просто так объявить автономию, а тимлидов отправить на мороз. Компания тестировала организационные изменения, проводила тренинги, и автономные команды таки сработали. Но только вовлеченность людей не выросла, а местами даже упала. Тогда процесс реорганизации начался с новой силой и тимлид вернулся, но уже с другой ролью.
Под катом подробности и современное устройство менеджмента в компании с 1500 сотрудников в IT.
О спикере: Георгий Могелашвили больше 10 лет в IT, последние четыре года работает в Booking.com в Амстердаме, 2 из них — тимлид.
Затронем три основные темы:
- Процесс эволюции (через что мы прошли за то время, пока я был в компании).
- Автономность — хорошо это или плохо, и почему у нас это было.
- Концепция Servant Leadership.
Я расскажу о том, что у нас сейчас и что такое тимлид в нашей организации на текущий момент.
Эволюция структуры Booking.com
Все знают наверняка, что главная страница booking.com выглядит примерно так:
Довольно известная желтая плашка с поиском, различные баннеры — все красиво, все с картинками. Но немногие люди в курсе, что на самом деле компания была основана в 1996 году в Амстердаме — мало кто знает, что так давно, и мало кто знает, что в Голландии, что это не американская компания. Booking.com действительно основана голландцами, только впоследствии куплена американцами.
В 1996 сайт компании выглядел вот так:
Здесь есть кнопка поиска, но нет формы поиска, нет, естественно, ничего интерактивного. Бронирования делались вручную по телефону. Когда кто-то отправлял заявку на сайте, хозяин — владелец компании сам брал телефон в руки, звонил в отель, говорил: «Здравствуйте, такой-то гость хочет к вам заехать. Можно, нет? Да? Отлично». Перезванивал клиенту и сообщал, что «Ваше бронирование подтверждено». Сейчас все, конечно, автоматизировано.
С тех пор компания очень выросла. В 2000 году было всего 8 сотрудников, в 2014 году, когда я пришел в компанию, было 6000 сотрудников, из них около 400 — в IT. На текущий момент у нас больше 15000 людей в 198 городах по всему миру. В IT работает более полутора тысяч людей, причем более половины работает меньше одного года. Мы растем стремительно и за последнее время очень сильно увеличили штат сотрудников в IT.
Я пришел в компанию в 2014 году, переехал из Москвы. В тот момент был всего один офис разработки — штаб-квартира в Амстердаме. Там работало 500 человек и совершалось примерно 600.000 бронирований комнат/ночей в день. В тот момент организационная структура компании выглядела таким образом, что было много-много Agile-команд по пять-шесть человек, у каждой есть тимлид и product owner.
Был уровень менеджмента, который располагался чуть выше, — это senior тимлид и senior product owner, в подчинении которых находилось несколько разных команд.
Дальше появляется chief technical officers и chief product officer.
Это все наши структуры менеджмента на 2014 год.
Роли тимлида и product owner
Эти два человека отвечали за то, чтобы команда работала успешно.
- Тимлид отвечал за организационные моменты, за процессы, за проведение различных митингов, взаимодействие с внешними командами, частично за рост людей, оценку их производительности, плюс писал код.
- Product owner занимался полностью продуктом: приоритезация и ведение бэклога, контроль различных метрик, отчет перед бизнесом, установка видения команды, чем она должна заниматься, а чем нет.
Когда я говорю код, это значит, что это либо backend, frontend, дизайн, либо любая другая роль человека, которую он занимал до того, как стал тимлидом. Тимлиды — не только бэкендеры. Тимлидами могут быть и фронтенд-разработчики, дизайнеры, копирайтеры, тестировщики. Все эти люди спокойно становятся тимлидами. У нас нет дискриминации по чему-либо.
Роль тимлида можно охарактеризовать примерно в таких пропорциях: это время, которое обычно тратит тимлид на различные задачи. Код и дизайн — это большая часть времени. Потом идет производительность команды и рост людей.
С течением времени мы начинаем расти. Мы понимаем, что скоро мы будем нанимать очень много людей. Задачи бизнеса растут. Нам необходимо расширяться, внедрять новые продукты, у нас появляются очень сильные конкуренты. Мы хотим с ними соперничать. Мы расширяем команду. Сначала был один офис, затем еще несколько. У нас 5 офисов по Амстердаму, где люди занимаются разработкой, и это не считая customer support и прочих офисов. В IT становится практически 1000 человек, мы бьём рекорд и делаем один миллион бронирований комнат/ночей в день.
Мы растем, и нужно как-то этот рост обеспечить. Мы хотим, чтобы люди вместе с нами понимали, что этот рост важен, и хотели работать на компанию, чтобы они хотели быть замотивированными, чтобы они выкладывались на полную, для того чтобы развивать компанию вместе с нами. Как этого добиться?
Мы провели небольшие исследования на рынке концепций, психологических программ и прочих вещей, как помочь замотивировать людей.
Мы нашли Autonomy Mastery Purpose, что можно охарактеризовать как:
- Дайте людям автономию, дайте больше ответственности и свободы.
- Позвольте им улучшать свое мастерство, расти как техническим специалистам.
- Поставьте перед ними понятные цели.
С помощью этих трех компонентов люди будут мотивированные, они захотят работать дальше и сами будут ответственны за свой собственный рост, за свою прогрессию. Но чтобы этого этого добиться, недостаточно прийти в команду и сказать: «Пацаны, теперь у вас полная свобода, автономия, вы молодцы. Давайте, работайте». При этом есть тимлид, к которому они привыкли и знали, что тимлид прикроет им спину, всегда разрешит конфликты. Просто так прийти и сказать, что вы теперь становитесь автономными при наличии тимлида, нельзя. Что делать?
В booking.com мы очень много ставим экспериментов на сайте. Мы очень часто проводим A/B-тестирования. Практически любая фича, которая выкатывается, проходит через эксперимент. Экспериментирование лежит в основе всех принципов того, как мы работаем. Логично, что и в этот раз мы решили сделать эксперимент и посмотреть, как можно оптимизировать процесс управления людьми и вообще организацию команд в целом.
Автономные команды
Так мы назвали этот эксперимент. Мы убираем тимлидов. Были тимлиды, а сейчас мы от них отказываемся и использовать их не будем. Как жить дальше — непонятно. Оставляем product owner’ов в команде, потому что полной анархии быть не должно. Продукт должен развиваться согласно какому-то четкому плану. За бизнес должен отвечать человек, который в специально обучен и понимает, какие бизнес-показатели важны и какие задачи стоит брать в работу.
Поскольку это эксперимент, и мы вводим его для нескольких команд, мы хотим измерить успех инициативы.
Мы планируем это делать через опрос, который мы называем Team Effectiveness. Опрос строится на Google research под названием Perfect Team. Там 7 основных критериев, таких как:
- psychological safety (по-русски — психологическая безопасность),
- способность работать автономно,
- способность принимать решения,
- вовлеченность и т.д.
На основе опроса мы будем сравнивать 82 команды из контрольной группы. Из них 24 команды автономные, и 58 команд остались старыми — с тимлидами — для сравнения. Будем взвешивать, где прибыло, а где убыло.
Если проиллюстрировать, то структура стала такая.
Появилось гораздо больше горизонтальных связей. Люди начали взаимодействовать друг с другом, начали общаться. Ответственность размылась, нет единственного человека или двух людей, которые отвечают за целостность команды. Мы распределили ответственность ровным слоем по разным людям.
bootcAMP
Просто так к этому не прийти. Нельзя просто сказать: «Ребята, есть тимлид Вася. С сегодняшнего дня он вам больше не нужен. Вася, спасибо, иди. Вы — автономные. Начинайте работать вместе». Конечно же, ни одна команда просто так автономной стать не сможет. Надо помочь этому процессу случиться. Для этого у нас были два основных концепта, первый из которых — bootcAMP.
bootcAMP — это двухдневный тренинг, который мы проводим для всех автономных команд на этапе их формирования. За два полных дня мы собираем команду вместе.
На тренинге проводим тимбилдинг, прокачиваем людей, которые раньше никогда об этом не думали, по soft skills:
- коммуникации,
- рефлексии,
- как давать фидбэк,
- как строить автономию в команде.
Мы начинаем их прокачивать в том, чем раньше занимался в основном тимлид в организации. Это активность, когда люди могут настроить какие-то связи между собой и договориться до чего-то, как они дальше будут работать в этой команде. Важным исходом этого тренинга является выработка договоренностей в команде — кто за что будет отвечать, как будем работать (например, во сколько стенд-ап митинги) и тому подобное. Важно, чтобы команда в итоге понимала, какие у нее цели и видение.
Kickstarter
Это второй пункт, который нам помогал развиваться и растить эти автономные команды. Kickstarter — это человек, который, как правило, раньше был тимлидом. Поскольку нельзя просто так выкинуть Васю на мороз, мы придумали ему роль кикстартер. Это человек, который помогал автономным командам в их становлении на первых порах. Он приходил в команду, проводил с ней 2-3 месяца, смотрел, чтобы все процессы были настроены как надо, чтобы люди взаимодействовали, чтобы машина автономии начала двигаться. После этого он уходил из команды, либо оставался.
Важный момент, если человек уходит из команды дальше быть кикстартером в другой команде, все хорошо. Если кикстартер по какой-то причине остается в команде, важно следить, чтобы он не начал ей руководить. Потому что, если человек в автономной команде берет на себя роль тимлида, потихонечку вся автономия опять стекается к этому человеку, и весь процесс насмарку.
Мы убрали тимлидов и, вроде, все складывается хорошо. Но возникают вопросы: а кто занимается теми вещами, которыми занимался раньше тимлид, как решать проблемы, как решать конфликты?
Раньше, если Маша не любит Петю, тимлид на это смотрит со стороны — ага, Маша с Петей почему-то плохо взаимодействует. Подойду и спрошу: «Маш, все хорошо? Как-то в последнее время не общаетесь». Она говорит: «Ты знаешь, он матом ругается, когда код пишет. Мне это не нравится». «Петя, слушай, тут Маша, девушка хрупкая, не любит, когда ты матом ругаешься. Давай поменьше». «Да, понял. Хорошо». Все, конфликт, надеюсь, что исчерпан.
Как происходит такое взаимодействие в автономных командах? Тимлида нет. Нет никого, кто бы мог помочь этот процесс как-то провести без потерь, чтобы они не переругались друг с другом. На самом деле у меня есть примеры, как в моей команде это работало в автономном формате. Я очень счастливый человек, потому что все примеры, которые буду приводить, они все работали, все было очень круто.
В нашей команде на bootcAMP’е, когда мы только формировались, мы договорились до того, что каждые две недели мы будем проводить ретроспективы. Причем ретроспективы не на то, как продукт развивался, как мы закрыли бэклог хорошо в прошлом спринте и так далее, а на то, как команда себя чувствует. Каждые две недели мы проверяли, а все ли хорошо у нас в команде, правильно ли мы движемся к автономии, правильно ли мы построили процессы, все ли у нас в порядке или есть какие-то конфликты.
Команда у нас состояла из одной девочки из Аргентины и трех русскоговорящих парней. Так уж получилось, русских везде много, в том числе в booking.com. Когда команда работает, на каком языке мы будем друг с другом общаться? Конечно, мы говорим, шутим, даже по работе что-то обсуждаем по-русски. Это стало ее напрягать, потому что она не понимала, о чем мы говорим. Ей учить русский — не вариант. Нам учить испанский — не вариант. Говорить по-английски между собой, когда все русские, тоже странновато. На одной ретроспективе она говорит: «Парни, вы знаете, у нас процесс идет хорошо, мы с вами все обсудили. Но есть у меня конкретный к вам момент. Говорите, пожалуйста, по-английски чаще или прекратите говорить по-русски рядом со мной. Я хочу тоже понимать, что происходит, а я не понимаю». Мы: «Да, наверное, правда. Мы не замечали. Спасибо, что ты нам сказала, мы обязательно примем к сведению информацию». Действительно мы со временем начали этот разговор вспоминать и, когда мы переключались на русский, то спустя какое-то время: «Блин, она же не понимает. Давайте переключимся на английский, включим ее в дискуссию и обсудим то, о чем мы сейчас планировали разговаривать». Это работало замечательно. Это один из примеров того, как коллективно мы могли обсудить какую-то проблему, которая назрела у нас в команде. Таких примеров было много.
Второй момент очень важный — как давать фидбэк. Когда есть тимлид, всегда понятно, что это человек, к которому можно прийти и поговорить, он посмотрит на твою производительность, даст тебе какую-то оценку и скажет, что тебе можно улучшать. Когда тимлида нет, где взять этого человека? Кто он? Куда пойти, с кем поговорить?
Мы решали это в нашей команде одним способом. Мы все это разделили на всю команду. Фидбэк мы давали друг другу. Мы составили небольшое расписание, где в неделю разбивались на пары и знали, что эта пара должна поговорить и обсудить, как они видят друг друга со стороны. Но пример о другом. Очень щекотливая тема — как выставлять оценки.
Ежеквартально у нас происходит ревью сотрудников, где выставляется оценка по шкале от 1 до 5 на основе того, как сотрудник поработал. Раньше этим занимался тимлид. У него есть полная картина, его обязанность поставить оценку, потому что он начальник. Сейчас начальника нет. Что делать в этой ситуации? Одна из команд решилась сделать это вместе за круглым столом, в открытую выставить друг другу оценки. Мы это переняли у них.
Я был тимлидом, я знаю, как происходит этот процесс. Во-первых, за эти оценки идет борьба, тебе нужно доказать почему так, а почему эдак. А тут я понимаю, что я сейчас приду в комнату, а там все другие люди, и они мне будут ставить оценки. Я вообще не понимаю, что происходит. Как быть-то? В первый раз было непонятно и неприятно, наверняка всем не нравилась эта идея, но никто не признавался. Я ходил: «Да, круто, офигенная идея, чуваки. Сейчас будем вместе калиброваться, будем вместе друг другу ставить оценки — отлично заживем!». А внутри думаю: «Блин, не заживем». Но зажили. Вы знаете, счастливая команда. Мне очень повезло.
Была ситуация, когда у нас один парень себе поставил очень высокую оценку, оценил себя на 4 по пятибалльной системе, а команда сказала, что это 2. Я думал, что сейчас разразится буря, но, к удивлению, то ли он был очень ответственный, то ли он забоялся, что мы его будем бить, но он сказал: «Да, ребята, спасибо за фидбэк. Вы действительно разложили по полочкам, дали мне понять, что есть проблема. Я буду с ней работать». В следующий квартал с поддержкой команды, когда мы уже знаем его точки улучшения (improvement points) с нашей поддержкой он улучшил свои показатели, он вырос постепенно с двоечки на троечку, с троечки на четверочку и стал отличным, классным парнем. У него просто были проблемы с коммуникациями. Мы ему потом постоянно давали фидбэк: «Лучше общайся с людьми».
Конечно, это не волшебство, его не бывает. Были и проблемы. Наша команда была такая уникальная, и все было в ней хорошо. Не все автономные команды, которые у нас были, работали так же сплоченно и классно. Я думал о том, почему такое могло быть. Наверное, потому что я был до этого тимлидом. Я понимал, как это работает. Я немножко направлял людей и помогал им сплачивать команду. Я был немножко тем кикстартером, который в команде остался. Нашей команде повезло. В других командах, конечно же, было похуже. Были команды, где все было очень плачевно.
В итоге с автономией в компании в целом, конечно же, были проблемы. Во-первых, это частая смена команд.
Если вы знаете модель Такмана, это модель стадий развития команд.
Существует четыре основных стадии:
- Forming — команда только сформировалась.
- Storming — люди какое-то время поработали друг с другом, но начинаются конфликты. Они что-то не понимают, не договариваются.
- Затем мы переходим в Norming — команда сформировалась, и более-менее люди друг друга понимают.
- Окончательная отличная стадия — это Performing. Все начинают работать, начинают офигенно драйвить.
Модель Такмана работает очень хорошо, но есть проблема — когда приходит в команду новый человек, то вы откатываетесь на шажок назад.
В booking.com такая специфика, что люди очень часто меняют команды. При найме мы говорим, что, в среднем, за год ты команду сменишь. Это просто особенности бизнеса, мы с этим ничего поделать не можем. Мы людей направляем туда, где больше приоритетов в компании, в бизнесе. Да и вообще возможность легко сменить команду это отличная мотивация и способ для роста наших сотрудников.
Представьте, есть автономная команда, все хорошо. У нас различные связи между людьми, они разных цветов, но люди как-то общаются друг с другом.
Тут приходит один новый человек — один ушел, один пришел — часть связей испарилась. Пришел еще один, еще какие-то связи пропали. Пришел новый PO, например, и там тоже все порушилось. В итоге мы имеем вот такую картину:
В этот момент, команда откатывается на одну стадию назад. Если команда была performing, пришел новый человек — команда откатилась назад и стала norming. Norming — это еще хорошо, быстренько можно восстановиться в performing. Приходит еще один человек — откатываемся еще назад и получаемся уже storm. А storm устанавливается в perform довольно тяжело, и тратится много сил. В этот момент приходит еще один новенький, и вот…
Очень много команд были подвержены такому эффекту, и многие команды так и не достигли стадии performing. Без лидера, без человека, который все время бы это контролировал, было очень трудно коллективу сплотиться самому по себе. BootсAMP-тренинг не проводится каждый раз при смене членов команды, и кикстартер не участвует каждый раз.
Еще одна проблема — это рост людей без поддержки.
Несмотря на то, что мы дали всем свободу, мы убрали тимлида, который раньше мог быть человеком, направляющим тебя в твоем росте. Разработчику, если он хочет стать ведущим разработчиком, надо совершить какие-то определенные шаги. Это не просто человек, который дольше всех в компании пишет код. Ему нужны необходимые качества. Как их приобрести и как понимать, что ты действительно на правильном пути? Тимлид раньше мог помочь, рассказать, направить, свести с нужными людьми, найти ментора, оказывать поддержку, давать фидбэк постоянно. В условиях автономной команды, даже при том, что у нас был фидбэк, размазанный по всей команде, и ты постоянно общался с людьми, не было того, с кем ты мог построить доверительные отношения и провести свой рост вместе с этим человеком.
Еще одна проблема — конечно же, нагрузка на senior тимлидов.
Представьте, был раньше менеджер, у которого в подчинении 5 других менеджеров. А сейчас этот же самый менеджер, а у него вместо 5 менеджеров 25 сотрудников, и всем нужно ставить оценки, со всеми нужно общаться, проводить one-on-one и что-то подобное. Нагрузка увеличилась в пять раз. Они, честно говоря, немножко подофигели. Мы пытались их вырастить, сделать больше senior тимлидов, но это не очень помогло.
Но самая главная проблема — падение engagement. Мы шли к увеличению engagement, мотивации и вовлеченности сотрудников.
По сравнению с командами, которые оставались с тимлидом, во многих командах engagement даже упал. В среднем, он не изменился. Это не помогло людям быть более вовлеченными. Надо что-то с этим делать.
Мы поняли, что в целом, автономия работает, автономия — это хорошо, но не в том виде, в котором она была у нас изначально. Очевидный вывод — надо вводить обратно тимлидов. Нужен человек, который бы управлял командой и контролировал ее.
В 2017 году мы подумали взять тимлида, постараться сохранить автономию и подружить их вместе. Родилась концепция Servant Leadership.
Servant Leadership
Согласно Википедии, Servant Leadership — это человек, который разделяет обязанности, ставит нужды других людей превыше всего и старается их развить как можно сильнее.
К чему все сводится? Команда была такая.
Потом стала такая.
Мы внедрили тимлида. Он такой же равноправный участник команды. Он точно так же со всеми строит горизонтальные связи, но при этом его роль — направляющая, он отвечает за то, чтобы команда развивалась. По сути, это тот kickstarter, про которого я говорил чуть ранее, но на постоянной основе: человек, который все время с командой, он всегда прикрывает спины людей, ответственен за то, чтобы люди в команде росли.
Важной отличительной особенностью нового тимлида servant leadership от предыдущего, который мини-начальничек, является адаптивность.
Вспомним модель Такмана: команда проходит через forming, storming, norming, performing. Хорошая иллюстрация адаптивности и сути servant leadership — вот, представим, что тумбочка — наша команда. Команда сейчас находится в forming’е. [Георгий встает перед тумбочкой]. Я, как тимлид, встаю перед командой и веду ее за собой. В какой-то момент я даже указываю что делать. Я строю процессы с нуля и веду людей за собой. Команда за лидером продолжает развиваться. Прошли стадию forming’а, переходим в storming, norming. В этот момент тимлид может отступить чуть-чуть назад и пойти с ними вместе рука об руку. [Георгий встает сбоку от тумбочки]. Вся команда, как единое целое, движется вперед к тому, чтобы стать успешной, стать развитой и производительной.
Мы дошли до определенного уровня развития. Команда стала самостоятельной, performing на отличном уровне. Тимлид уже не так нужен. Он отходит назад и оставляет команду работать так, как она работает. [ Георгий переходит за тумбочку]. В этот момент я могу сфокусироваться на коде, могу заниматься другими вещами, уже не особо заботясь о том, что команда требует моего внимания. Конечно, я слежу, чтобы все было хорошо, потому что в какой-то момент я могу опять прийти сюда. [ Георгий опять встает сбоку от тумбочки]. Пришел, например, новый сотрудник, я встал рядышком и помогаю ему влиться в коллектив. Я могу выйти сюда [Георгий встает перед тумбочкой], а могу вообще обойти и встать с другой стороны — вариантов много.
Основная, ключевая особенность servant leadership — это адаптивность тимлида к текущей ситуации. Это не только начальник, не человек, к которому всегда идут с вопросами и всегда знают, что он решит. Это человек, который умеет так построить процессы в команде, что в какой-то момент люди начинают работать без его участия. Я могу уйти в отпуск, и ничего не изменится. Меня могут уволить и ничего не изменится.
Servant Leader теперь гораздо больше времени уделяет росту людей и производительности команды.
Но при этом важно понимать, что эти надписи на этой картинке — производительность, рост людей и др. — это не обязанности конкретного тимлида. Это зоны ответственности, которые тимлид должен настраивать и отвечать за них. Но это не значит, что он сам этим занимается. Он должен построить среду, в которой люди будут расти, будут друг другу помогать, в которой команда станет производительной и будет делегировать фичи так, как мы этого ожидаем. Но ни в коем случае это не человек, который говорит и указывает, что делать, и является по сути командиром.
Если сравнить старого и нового тимлида, то видно, что рост и производительность стали гораздо большими секторами на диаграмме.
Как добиться автономности? Ее нельзя построить просто так. Нужно сначала добиться от людей доверия. Сделать это нелегко. С каждым человеком абсолютно по-разному. Но хорошей практикой станет показ того, что ты тоже человек и тоже уязвим. Например, поделиться каким-то переживанием.
На bootcAMP у нас была такая вещь: каждый рассказывал свою историю жизни, как он дошел до сегодняшнего дня. Надо было нарисовать диаграмму взлетов и падений, хорошие и плохие моменты в твоей жизни, как ты пришел сюда, и где ты сейчас себя ощущаешь. Через такую активность очень легко показать, что в какой-то момент у тебя было очень плохо: бросила девушка, уволили с работы, сломал ногу и все это в один день. Тебе было очень тяжело и печально. Ты тоже человек, ты это переживал. Или, например, когда ты стал тимлидом, в первый день ты думаешь: «Что происходит? Как мне дальше работать?». Да, это такая боль, и поделиться этой болью с людьми, сказать: «Вы знаете, я тоже очень сильно переживал. Я переживаю сейчас за вас, как вы, моя команда, будете работать, все ли будет хорошо. Мне ужасно волнительно». Люди начинают потихонечку думать: «Так он же нормальный. Он же тоже вроде как-то переживает, боится чего-то. Значит нормальный, с ним можно работать». И потихонечку доверие восстанавливается и строится.
Дать возможность выбора, распределить ответственность, предоставить возможности — это ключевые моменты автономии. На картинке собака, которая застряла в заборе.
Тут два варианта. Или помочь ей выбраться — подойти, как-то вытолкать оттуда и вытащить. Она тогда будет думать, что хозяин всегда поможет. Или постоять, потыкать пальцем в нее, посмеяться, сказать: «Что ж ты такая глупая, залезла в забор, давай вылезай». Через какое-то время, наверное, собака как-то задом попятится, с трудом, может быть, не сразу поймет, что происходит, поскулит, но выберется. В следующий раз она выберется сама, уже без вашего участия. Это подход к автономии, к тому, как ваша команда должна работать.
Важно помнить, что автономия — НЕ:
- работа в одиночку;
- анархия;
- беспечность;
- вседозволенность.
Это работа всем вместе над общим делом, и в нашем случае сейчас под прикрытием такой шапочки из тимлида.
Где взять тимлидов
У нас было 28 автономных команд, которые стали резко не автономными. Откуда должны появиться тимлиды? Это проблема.
Тут два пути решения. Первый — вырастить самим.
Мы это делаем довольно успешно. Находим людей, которые потенциально могут и хотят быть тимлидами. Для них проводим тренинги, тот же самый bootcAMP, но уже другой, чисто для тимлидов. Это тоже двухдневный тренинг, куда приходят люди, которые собираются стать тимлидами. Их там учат, поддерживают и делают все возможное для того, чтобы они поняли, что такое servant leadership и как построить автономию в командах, а затем вести вперед.
Три других пункта — это Booking Agile Essentials (BAE). Мы выработали такой framework, который помогает определять, все ли в команде хорошо. Это должны быть стендапы, ретроспективы, KPI, видение в команде и OKR — Objective and Key Results. Просто framework, вычеркивая галочки в котором, ты можешь для себя понять, что у меня в команде все так, как ожидалось.
Еще у нас есть Agile coach’и, которых стало гораздо больше в компании с учетом всех трансформаций. Мы наняли их достаточное количество. Они помогают тимлидам и командам в насущных вопросах. Помимо просто коучинга и работы с людьми на персональном уровне, это и помощь в проведении митингов, и какая-то другая работа с командами в случае, если есть необходимость, чтобы помочь тимлиду, чтобы он не занимался всем этим.
Второй вариант решения поиска тимлидов — это их найм.
Мы раньше никогда такого не делали. Мы всегда нанимали только разработчиков и дизайнеров. Тимлидов мы никогда особо не нанимали, потому что мы не знали, как их правильно интегрировать в команду. Должен быть человек, который знает Booking, как мы работаем, знает его особенности. Сейчас мы понимаем, что нельзя больше так жить. Нам нужен кто-то со стороны, потому что мы внутри не успеваем вырастить столько тимлидов, сколько нам необходимо. Поэтому мы проводим поиск кандидатов по всему миру, перевозим их к нам в штаб-квартиру, обучаем и растим. Тот же самый bootcAMP, тренинги и испытательный срок, чтобы они влились в компанию и поняли, как все работает. Таким образом, тоже закрываем дырки в тимлидстве. Кстати, если вы хотите стать одним из тимлидов в букинге, то можете смело переходить по этой ссылке.
Несколько выводов:
- Меняться можно и нужно. Это не очень плохо. Не думайте, что если у вас всегда какая-то одна концепция работала, то она будет работать всю жизнь. Не всегда. Пробуйте, экспериментируйте, внедрите автономную команду, если вы понимаете, что у вас люди недостаточно мотивированы, недостаточно самостоятельны. Внедрите Servant Leadership, если вы знаете сразу, как его внедрить. Посмотрите на варианты, почитайте литературу. Вариантов много. Меняться — это хорошо.
- Автономия — это не страшно. Это звучит страшно, потому что непонятно. Никто никогда так раньше, вроде, не делал, не пробовал. А что будет, если люди начнут разбредаться, тянуть как лебедь, рак и щука, в разные стороны свои команды. С этим можно совладать. Нужны, конечно же, процессы, нужна помощь, поддержка Agile coach’ей, возможно, тимлидов, если сохранить их под концепцией Servant Leadership, например. Это нормально. Это неплохо и не страшно. Это, наоборот, хорошо. Люди начинают думать не только о том, за что они отвечают, но о чем-то более глобальном.
- Быть лидером, а не боссом! Как пример с той собакой или как в притче о рыбаке и рыбе: дай человеку рыбу, и он будет сыт один день, дай человеку удочку — он будет сыт всю жизнь. Надо стараться так, чтобы своим людям всегда давать удочку, чтобы они знали, как решать свои вопросы самостоятельно. Первый раз помочь, а дальше уже сами.
Георгий Могелашвили входит в Программный комитет Saint TeamLead Conf и планирует провести круглый стол на тему «Как измерить программиста?» Посмотрите, какие еще заявки мы получили, и присоединяйтесь к обсуждению болей тимлида.
Автор: romas1982
