Хабрахабр

Из закрытой касты в Servant Leadership: эволюция тимлида в Booking.com

На пути от традиционной иерархии 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. С тех пор компания очень выросла. В IT работает более полутора тысяч людей, причем более половины работает меньше одного года. На текущий момент у нас больше 15000 людей в 198 городах по всему миру. Мы растем стремительно и за последнее время очень сильно увеличили штат сотрудников в IT.

В тот момент был всего один офис разработки — штаб-квартира в Амстердаме. Я пришел в компанию в 2014 году, переехал из Москвы. 000 бронирований комнат/ночей в день. Там работало 500 человек и совершалось примерно 600. В тот момент организационная структура компании выглядела таким образом, что было много-много 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, что можно охарактеризовать как:

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

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

Мы очень часто проводим A/B-тестирования. В booking.com мы очень много ставим экспериментов на сайте. Экспериментирование лежит в основе всех принципов того, как мы работаем. Практически любая фича, которая выкатывается, проходит через эксперимент. Логично, что и в этот раз мы решили сделать эксперимент и посмотреть, как можно оптимизировать процесс управления людьми и вообще организацию команд в целом.

Автономные команды

Так мы назвали этот эксперимент. Мы убираем тимлидов. Были тимлиды, а сейчас мы от них отказываемся и использовать их не будем. Как жить дальше — непонятно. Оставляем product owner’ов в команде, потому что полной анархии быть не должно. Продукт должен развиваться согласно какому-то четкому плану. За бизнес должен отвечать человек, который в специально обучен и понимает, какие бизнес-показатели важны и какие задачи стоит брать в работу.

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

Опрос строится на Google research под названием Perfect Team. Мы планируем это делать через опрос, который мы называем Team Effectiveness. Там 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. В этот момент, команда откатывается на одну стадию назад. Приходит еще один человек — откатываемся еще назад и получаемся уже storm. Norming — это еще хорошо, быстренько можно восстановиться в performing. В этот момент приходит еще один новенький, и вот… А storm устанавливается в perform довольно тяжело, и тратится много сил.

Без лидера, без человека, который все время бы это контролировал, было очень трудно коллективу сплотиться самому по себе. Очень много команд были подвержены такому эффекту, и многие команды так и не достигли стадии performing. BootсAMP-тренинг не проводится каждый раз при смене членов команды, и кикстартер не участвует каждый раз.

Еще одна проблема — это рост людей без поддержки.

Разработчику, если он хочет стать ведущим разработчиком, надо совершить какие-то определенные шаги. Несмотря на то, что мы дали всем свободу, мы убрали тимлида, который раньше мог быть человеком, направляющим тебя в твоем росте. Ему нужны необходимые качества. Это не просто человек, который дольше всех в компании пишет код. Тимлид раньше мог помочь, рассказать, направить, свести с нужными людьми, найти ментора, оказывать поддержку, давать фидбэк постоянно. Как их приобрести и как понимать, что ты действительно на правильном пути? В условиях автономной команды, даже при том, что у нас был фидбэк, размазанный по всей команде, и ты постоянно общался с людьми, не было того, с кем ты мог построить доверительные отношения и провести свой рост вместе с этим человеком.

Еще одна проблема — конечно же, нагрузка на senior тимлидов.

А сейчас этот же самый менеджер, а у него вместо 5 менеджеров 25 сотрудников, и всем нужно ставить оценки, со всеми нужно общаться, проводить one-on-one и что-то подобное. Представьте, был раньше менеджер, у которого в подчинении 5 других менеджеров. Они, честно говоря, немножко подофигели. Нагрузка увеличилась в пять раз. Мы пытались их вырастить, сделать больше senior тимлидов, но это не очень помогло.

Мы шли к увеличению engagement, мотивации и вовлеченности сотрудников. Но самая главная проблема — падение engagement.

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

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

Родилась концепция Servant Leadership. В 2017 году мы подумали взять тимлида, постараться сохранить автономию и подружить их вместе.

Servant Leadership

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

Команда была такая. К чему все сводится?

Потом стала такая.

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

Важной отличительной особенностью нового тимлида servant leadership от предыдущего, который мини-начальничек, является адаптивность.

Хорошая иллюстрация адаптивности и сути servant leadership — вот, представим, что тумбочка — наша команда. Вспомним модель Такмана: команда проходит через forming, storming, norming, performing. [Георгий встает перед тумбочкой]. Команда сейчас находится в forming’е. В какой-то момент я даже указываю что делать. Я, как тимлид, встаю перед командой и веду ее за собой. Команда за лидером продолжает развиваться. Я строю процессы с нуля и веду людей за собой. В этот момент тимлид может отступить чуть-чуть назад и пойти с ними вместе рука об руку. Прошли стадию forming’а, переходим в storming, norming. Вся команда, как единое целое, движется вперед к тому, чтобы стать успешной, стать развитой и производительной. [Георгий встает сбоку от тумбочки].

Команда стала самостоятельной, performing на отличном уровне. Мы дошли до определенного уровня развития. Он отходит назад и оставляет команду работать так, как она работает. Тимлид уже не так нужен. В этот момент я могу сфокусироваться на коде, могу заниматься другими вещами, уже не особо заботясь о том, что команда требует моего внимания. [ Георгий переходит за тумбочку]. [ Георгий опять встает сбоку от тумбочки]. Конечно, я слежу, чтобы все было хорошо, потому что в какой-то момент я могу опять прийти сюда. Я могу выйти сюда [Георгий встает перед тумбочкой], а могу вообще обойти и встать с другой стороны — вариантов много. Пришел, например, новый сотрудник, я встал рядышком и помогаю ему влиться в коллектив.

Это не только начальник, не человек, к которому всегда идут с вопросами и всегда знают, что он решит. Основная, ключевая особенность servant leadership — это адаптивность тимлида к текущей ситуации. Я могу уйти в отпуск, и ничего не изменится. Это человек, который умеет так построить процессы в команде, что в какой-то момент люди начинают работать без его участия. Меня могут уволить и ничего не изменится.

Servant Leader теперь гораздо больше времени уделяет росту людей и производительности команды.

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

Если сравнить старого и нового тимлида, то видно, что рост и производительность стали гораздо большими секторами на диаграмме.

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

Надо было нарисовать диаграмму взлетов и падений, хорошие и плохие моменты в твоей жизни, как ты пришел сюда, и где ты сейчас себя ощущаешь. На bootcAMP у нас была такая вещь: каждый рассказывал свою историю жизни, как он дошел до сегодняшнего дня. Тебе было очень тяжело и печально. Через такую активность очень легко показать, что в какой-то момент у тебя было очень плохо: бросила девушка, уволили с работы, сломал ногу и все это в один день. Или, например, когда ты стал тимлидом, в первый день ты думаешь: «Что происходит? Ты тоже человек, ты это переживал. Да, это такая боль, и поделиться этой болью с людьми, сказать: «Вы знаете, я тоже очень сильно переживал. Как мне дальше работать?». Мне ужасно волнительно». Я переживаю сейчас за вас, как вы, моя команда, будете работать, все ли будет хорошо. Он же тоже вроде как-то переживает, боится чего-то. Люди начинают потихонечку думать: «Так он же нормальный. И потихонечку доверие восстанавливается и строится. Значит нормальный, с ним можно работать».

На картинке собака, которая застряла в заборе. Дать возможность выбора, распределить ответственность, предоставить возможности — это ключевые моменты автономии.

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

Важно помнить, что автономия — НЕ:

  • работа в одиночку;
  • анархия;
  • беспечность;
  • вседозволенность.

Это работа всем вместе над общим делом, и в нашем случае сейчас под прикрытием такой шапочки из тимлида.

Где взять тимлидов

У нас было 28 автономных команд, которые стали резко не автономными. Откуда должны появиться тимлиды? Это проблема.

Первый — вырастить самим. Тут два пути решения.

Находим людей, которые потенциально могут и хотят быть тимлидами. Мы это делаем довольно успешно. Это тоже двухдневный тренинг, куда приходят люди, которые собираются стать тимлидами. Для них проводим тренинги, тот же самый bootcAMP, но уже другой, чисто для тимлидов. Их там учат, поддерживают и делают все возможное для того, чтобы они поняли, что такое servant leadership и как построить автономию в командах, а затем вести вперед.

Мы выработали такой framework, который помогает определять, все ли в команде хорошо. Три других пункта — это Booking Agile Essentials (BAE). Просто framework, вычеркивая галочки в котором, ты можешь для себя понять, что у меня в команде все так, как ожидалось. Это должны быть стендапы, ретроспективы, KPI, видение в команде и OKR — Objective and Key Results.

Мы наняли их достаточное количество. Еще у нас есть Agile coach’и, которых стало гораздо больше в компании с учетом всех трансформаций. Помимо просто коучинга и работы с людьми на персональном уровне, это и помощь в проведении митингов, и какая-то другая работа с командами в случае, если есть необходимость, чтобы помочь тимлиду, чтобы он не занимался всем этим. Они помогают тимлидам и командам в насущных вопросах.

Второй вариант решения поиска тимлидов — это их найм.

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

Несколько выводов:

  • Меняться можно и нужно. Это не очень плохо. Не думайте, что если у вас всегда какая-то одна концепция работала, то она будет работать всю жизнь. Не всегда. Пробуйте, экспериментируйте, внедрите автономную команду, если вы понимаете, что у вас люди недостаточно мотивированы, недостаточно самостоятельны. Внедрите Servant Leadership, если вы знаете сразу, как его внедрить. Посмотрите на варианты, почитайте литературу. Вариантов много. Меняться — это хорошо.
  • Автономия — это не страшно. Это звучит страшно, потому что непонятно. Никто никогда так раньше, вроде, не делал, не пробовал. А что будет, если люди начнут разбредаться, тянуть как лебедь, рак и щука, в разные стороны свои команды. С этим можно совладать. Нужны, конечно же, процессы, нужна помощь, поддержка Agile coach’ей, возможно, тимлидов, если сохранить их под концепцией Servant Leadership, например. Это нормально. Это неплохо и не страшно. Это, наоборот, хорошо. Люди начинают думать не только о том, за что они отвечают, но о чем-то более глобальном.
  • Быть лидером, а не боссом! Как пример с той собакой или как в притче о рыбаке и рыбе: дай человеку рыбу, и он будет сыт один день, дай человеку удочку — он будет сыт всю жизнь. Надо стараться так, чтобы своим людям всегда давать удочку, чтобы они знали, как решать свои вопросы самостоятельно. Первый раз помочь, а дальше уже сами.

Георгий Могелашвили входит в Программный комитет Saint TeamLead Conf и планирует провести круглый стол на тему «Как измерить программиста?» Посмотрите, какие еще заявки мы получили, и присоединяйтесь к обсуждению болей тимлида.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть