Небольшие команды и «однопоточные» лидеры
Многие проблемы очень трудно решить «сверху вниз».
В 1998 г. мой друг Дэйв Шаппелл (нет, не комик Дэйв Шаппелл!) стал примерно сотым сотрудником молодой компании . Он помог запустить Amazon Marketplace, Amazon Associates, Amazon Auctions и некоторые другие платформы. Именно он пригласил меня в AWS в 2004 г. К тому времени в компании работало уже примерно 5000 человек, а Дэйв покинул Amazon, чтобы основать стартап TeachStreet. Восемь лет спустя, в 2012 г., Amazon приобрела этот стартап, и Дэйв снова оказался в этой компании, где к тому времени работало более 75 000 человек.
Вскоре после его возвращения в Amazon в 2012 г. я позвонил ему с простым вопросом: «Чем, на твой взгляд, отличаются три компании — Amazon со 100, с 5000 и теперь с 75 000 сотрудников?» Он задумался на несколько мгновений, а затем сказал следующее: «Знаешь, это одна и та же компания. То же чувство срочности. Та же быстрая походка сотрудников. Тот же интеллект. Это потрясающе». В 1998 г. в офисе Amazon в Сиэтле был один этаж, полный сотрудников, полный суеты и энергетики, свойственной для стартапа. В 2012 г. картина осталась той же, только таких этажей, занятых стартапами Amazon, было почти тысяча по всему миру. Способность Amazon масштабировать свою культуру с таким размахом действительно поражает.
Как руководители, мы постоянно стремимся придать ауру важности и срочности работе, выполняемой нашими командами. Однако по мере того, как компания становится больше, практически всегда рабочие процессы замедляются, люди теряют связь с работой, верх берет политика, а ощущение срочности ослабевает — это почти реальная угроза. Однако по крайней мере, по словам моего друга Дэйва, Amazon избежала этой участи. Независимо от того, крупная у вас компания, пытающаяся вернуть былую живость, или небольшая, стремящаяся вырасти и не потерять свои преимущества, что полезного вы можете извлечь из успешного масштабирования, описанного Дейвом? В основе масштабирования Amazon лежат небольшие команды с самостоятельными и ориентированными на миссию руководителями. По сути, это собрание стартапов.
Смотрите на это так: стартап действует быстро и смело, поскольку иначе он не может. Из-за малого размера у него не слишком много накладных расходов и линии коммуникации ясны. Присутствие основателя, генерального директора или, самое большее, небольшой группы соучредителей и руководителей, быстро принимающих решения и чувствующих ответственность за результаты, делает эти результаты личными. Если побеждает компания, то побеждают и они. Если компания проигрывает, то проигрывают и они.
То же самое можно сказать и о небольших командах в крупной компании, и именно поэтому они имеют решающее значение. Структура Amazon, состоящая из команд численностью не более 10 человек, позволяет масштабировать компанию без потери чувства срочности, сфокусированности и качества талантов, характерных для стартапа. Помимо прочего, она не затрудняет сотрудничество, которое только усиливается с увеличением размера компании. Сложность координации деятельности компании по мере ее роста возрастает почти экспоненциально. Если вы сталкиваетесь с подобным в своей компании, знайте: в этом не ваша вина, это простая математика. Координация команды из 10 человек требует 45 связей между людьми, из 100 человек — почти 5000 связей, а из 1000 человек — почти 500 000. Amazon со штатом 75 000 человек в 2012 г. могло бы потребоваться 2,8 млрд связей, что сделало бы ее в 500 000 раз более сложной и запутанной по сравнению с компанией из 100 человек, которой она была вначале. Но этого не случилось. Это по-прежнему та же компания — современное чудо, построенное на основе небольших команд.
Происхождение команды на две пиццы
На рубеже тысячелетий Amazon была быстрорастущим стартапом, но ее обновление начало замедляться. По словам тогдашнего директора по информационным технологиям (а ныне — члена правления компании Twilio) Рика Далзелла, кодовая база была невероятно запутанной, а в разработке продукта было несколько крупных направлений вроде обзора и поиска, обработки заказов и корзины покупок. Работа замедлялась, а с кодом становилось работать все сложнее, поскольку им занималось слишком много людей. Помимо проблем с кодом, наблюдался избыток тех, кто принимает решения, — и они вмешивались в работу каждого, поскольку все было тесно взаимосвязано. Как вы понимаете, это сильно напрягало инженеров и менеджеров по продукту, которые пытались реализовать свои идеи, но больше всего это обескураживало генерального директора Amazon Джеффа Безоса.
Почти каждый год Джефф брал неделю на то, чтобы оторваться от дел и спокойно поразмышлять о бизнесе. Эти ежегодные «мозговые штурмы» давали время переосмыслить существующие принципы и завершались обычно появлением ряда одностраничных документов с новыми идеями, которые представлялись команде руководителей. Рик рассказывает, как в 2001 г. Джефф отправился в свой ретрит, озабоченный проблемой замедления темпов обновления. Вернулся он с простой идеей: если создать небольшие команды, дать им свои задачи и сделать владельцами кода, то они снова смогут действовать подобно стартапам, как на заре существования Amazon, когда, по воспоминаниям Джеффа, всю команду можно было накормить двумя пиццами. Но для совместной работы требовалась масса API, обеспечивавших взаимодействие. Это позволило бы действовать независимо, а взаимоотношения команд регулировались бы технологией. Так одностраничный документ дал начало «командам на две пиццы». Рик вернулся к своим подчиненным и в течение недели превратил идею Джеффа в шестистраничный рабочий план, который Amazon быстро приняла.
Команды на дюжину рогаликов
Мы в Twilio к тому времени уже начали преобразовывать компанию в небольшие команды, а разговор в 2012 г. с Дэйвом Шаппеллом лишь укрепил меня во мнении, что это лучший путь масштабирования компании без потери существующих преимуществ.
В самом начале существования в Twilio было всего три разработчика (они же основатели) — это Эван, Джон и я. При таких размерах мы могли держать весь бизнес в голове. В любой момент мы могли выдвинуть новую идею, написать код, поддержать клиентов по электронной почте или телефону, оплатить счета и даже съездить в магазин Costco, чтобы купить канцелярские принадлежности. Мы постоянно создавали демонстрационные приложения поверх наших API и поэтому знали, как обслуживаются наши клиенты. Осуществляя клиентскую поддержку, мы инстинктивно понимали, чего хотят добиться клиенты, где мы дали промашку и куда нужно инвестировать.
Один раз, помню, клиент сообщил в Twitter о нашей ошибке, и я за пять минут написал исправление, но отложил его внедрение на день, поскольку не хотел, чтобы мы казались слишком маленькой компанией. Это было просто исправление ошибки, но случалось, что мы брали идеи клиентов и превращали их в целостные продукты за несколько дней. Одним из них является наша система «субаккаунтов», позволяющая разработчикам сегментировать использование сервисов Twilio на пакеты. Это полезно для софтверных компаний, создающих на основе Twilio свои продукты для многочисленных клиентов. Мы поняли, что такая функция будет полезна, и я написал ее за ночь и добавил на следующий день.
Когда Эвану, Джону и мне нужно было принять решение, мы обычно делали это быстро. Ежедневно мы вплотную занимались переговорами с клиентами, обсуждением архитектуры нашего ПО и совмещением его частей. Мы могли представить, чем обернутся наши решения со временем. Хотя у каждого из нас была своя специализация (Эван писал программы поддержки вычислительной техники, Джон создавал базовые сервисы, а я — API и программы для работы с интернетом и выставления счетов), мы знали достаточно много, чтобы действовать как единый мозговой центр. Когда вы держите всю картину в голове и работаете вместе каждый день, то можете добиваться результата невероятно быстро. В этом сила небольшой команды — в ней нет промежуточных звеньев; вы просто решаете проблемы клиентов напрямую.
В этом и заключается магия, которая делает стартапы такими особенными и продуктивными: у них очень низкие расходы на управление, затраты энергии на координацию ничтожны, а сотрудники имеют сильную внутреннюю мотивацию, поскольку они близки к клиентам и, следовательно, к своей миссии. Успех или провал стартапов зависит от множества факторов, но мотивации и скорости у них обычно хватает. Кому бы не хотелось иметь такую энергию в своем бизнесе? Я ни разу не встречал руководителя, который не хотел бы, чтобы его сотрудники обладали такой внутренней мотивацией и стремлением к успеху, но то, как мы обычно структурируем компании, убивает эти качества. Наши организационные структуры отделяют сотрудников от клиентов, наши процессы принятия решений заставляют сотрудников чувствовать себя лишенными власти, а целью компании становится успех, а не обслуживание клиентов. Почти все компании по мере своего роста в той или иной степени действуют именно так.
В первое время наша троица начинала рабочую неделю с совещания в понедельник, и я по пути на работу покупал нам рогалики, точнее, три рогалика. По мере того, как росла наша компания, увеличивалось и число присутствующих на совещаниях в понедельник, а вместе с этим и количество рогаликов. Вскоре я покупал полдюжины рогаликов, затем дюжину, потом две дюжины, три… С ростом объема закупок рогаликов мне становилось все труднее и труднее держать весь бизнес в голове (как, впрочем, и нести рогалики). Кроме того, я заметил, что наш способ управления компанией уже не так эффективен. Сотрудники перестали видеть картину в целом нашего бизнеса и внутренне чувствовать план, как, бывало, его чувствовали мы, когда нас было трое. Наши работники оказались в изоляции, инженеры уже не общались с клиентами — это делала только команда поддержки. Одни сотрудники работали над нашим первым продуктом Twilio Voice, другие создавали второй продукт Twilio SMS, а третьи занимались инфраструктурой. Каждый знал, над чем он работает, но не представлял полной картины. Я также понял, что у новых сотрудников не было такого же опыта, как у нас троих, — многие новые инженеры не видели запросов в службу поддержки, а новым сотрудникам службы поддержки не приходилось создавать приложения на Twilio, и они не вникали в детали продукта.
В нашей команде уже было около 30 человек, и ситуация все больше беспокоила меня, впрочем, как и всех остальных. Было непонятно, почему сотрудники не могли видеть полную картину так же, как когда-то ее видели мы с Эваном и Джоном. Однажды я присутствовал на совещании руководителей компаний, которое организовал один из моих первых инвесторов, Альберт Венгер из Union Square Ventures (USV). На вопрос, как идут дела, я честно (как обычно) ответил: «Дела идут дерьмово, в нашей команде больше ничего не работает». Фред Уилсон, соучредитель USV, попросил меня нарисовать нашу организационную структуру, чего я никогда раньше не делал.
Я взял маркер и нарисовал следующее:
Линия тянулась далее… Большая прямая линия с именами 30 с чем-то человек, которые все как один подчинялись мне!
«Вот в чем твоя проблема», — с ходу и совершенно правильно заявил Альберт. Я никогда раньше не думал об организационной структуре. Мы просто нанимали людей, которые, как и все до них, подчинялись напрямую мне. Как только численность нашего персонала вышла за пределы 10 человек, прямолинейная организационная структура стала мешать работе, что стало очевидно, как только я нарисовал ее. Проблема заключалась в том, что мы выросли и наша команда перестала воспринимать в целом то, чем мы занимались. Поэтому я вернулся с совещания с намерением разделить компанию на более мелкие команды, оставалось только решить, по какому принципу.
Первое очевидное решение — деление по функциональному принципу: ответственные за поддержку клиентов работают вместе, инженеры работают вместе, менеджеры по продукту работают вместе и т.д. Вспоминая те дни, когда Эван, Джон и я втроем занимались поддержкой клиентов, проектировали продукты и писали код, я ломал голову над тем, как сохранить этот подход в масштабе всей команды в процессе роста.
Прежде всего мы внедрили идею, что все сотрудники должны в какой-то мере заниматься поддержкой клиентов — не все время, конечно, а для сохранения связи с клиентами. Мы стали предлагать всем новым сотрудникам в течение первых двух недель обработать по полсотни обращений в службу поддержки, чтобы узнать наших клиентов, наш продукт и наш подход к обслуживанию клиентов. Мы также стали просить всех новых сотрудников создать приложение с использованием Twilio — причем не только разработчиков, а всех подряд. Торговым представителям и агентам по работе с клиентами это, несомненно, идет на пользу. Но мы ставили такую задачу юристам, бухгалтерам, аналитикам (всем без исключения) — создать что-нибудь с помощью сервисов Twilio и таким образом познакомиться с тем, какие возможности мы предоставляем клиентам. Цель заключалась в том, чтобы выстроить как можно больше связей между нашими сотрудниками и клиентами. И по сей день каждый новый «твилион» независимо от своей роли в компании изучает основы кодирования и создает приложение на нашей платформе. После завершения работы над своим приложением он получает красную спортивную куртку Twilio — своего рода почетный знак компании.
Самым значимым изменением стало преобразование нашего подхода к работе в небольших командах в структуру на основе команд. Мы разделили группу из 30 с лишним человек на три команды: Twilio Voice (уже существующий продукт), Twilio SMS (наш будущий продукт) и Twilio Infrastructure (наши внутренние платформы), каждую из которых можно было накормить дюжиной рогаликов (в продолжение традиции Twilio).
В тот момент это был очевидный подход к структурированию компании, но по мере роста команд мы повторяли процесс их деления на небольшие стартапы. Когда у вас есть два продукта и определенная инфраструктура, это просто. Но раз за разом разделять команды на протяжении многих лет сложнее, чем кажется, поскольку существует тысяча способов реализации этой идеи. Этому мы как раз и научились за последнее десятилетие в процессе расширения от трех команд до более чем 150.
Клиент, миссия и показатели
Чтобы команда обрела внутреннюю мотивацию стартапа, ей нужны организационные принципы, в которых сформулирована цель. Обычно я начинаю с определения клиента, которого она обслуживает. Это может быть внешний клиент в традиционном смысле или внутренний клиент. Для команды, разрабатывающей продукт, идентификация потребительского сегмента или персоны может быть полезной. Например, эта команда создает продукты для малого бизнеса, а эта — для индивидуальных потребителей. Это довольно очевидная часть создания нового направления. Но это менее очевидно для команды, ориентированной на внутреннего клиента, а потому требует ясного формулирования и документирования. Например, команда Twilio Infrastructure, о которой я упоминал ранее, прямо заявила, что их «клиентами» являются другие внутренние разработчики Twilio. Это помогает понять, зачем ее члены ежедневно идут на работу. Если им нужно выяснить, куда двигаться, они должны расспрашивать клиентов об их насущных проблемах. В отсутствие клиента направление работы задает тот, кто кричит громче всех или имеет самую большую зарплату. Наличие клиента сводит все к выяснению того, что он хочет.
После определения клиента наступает очередь миссии. Это не маркетинговое упражнение вроде подготовки заявления о миссии компании. Речь идет о ключевой цели, которую команда принимает сама и вокруг которой она может сплотиться. Для команды, занимающейся инфраструктурой, это может быть «максимизация производительности наших инженеров при создании, тестировании, выпуске и эксплуатации высококачественных продуктов для интернета». Чтобы члены команды действительно верили в миссию, ее формулировка должна быть понятной, легко запоминающейся и лишенной жаргонизмов.
Наконец, для оценки прогресса в достижении миссии и того, насколько хорошо обслуживаются клиенты, необходимы показатели успеха. Многие компании называют это системой управления по целям или системой целей и ключевых результатов. Название может быть любым, но я считаю, что показатели должны быть долгосрочными, отражающими историю прогресса в достижении заявленной миссии, а не ежеквартально меняющимися. Например, когда началась разработка платформ Twilio Infrastructure, наша система сборки, упаковывающая код для развертывания на серверах, была ужасно ненадежна. Сборка и развертывание нашего ПО могло занять полдня, и половина времени сборка оказывалась неудачной по неизвестным причинам. Это сводило на нет производительность разработчиков. Так вот, команда, занимающаяся инфраструктурой, ввела показатель «время от регистрации кода до его развертывания». В краткосрочной перспективе было ясно, что им предстоит провести разбор существующей ситуации, но в долгосрочной перспективе этот показатель явно характеризовал производительность разработчиков, на которую могла влиять команда Twilio Infrastructure. Обратите внимание, что это не было «исправление системы сборки» или «уменьшение количества ошибок с 50 до 5%», которые представляли собой краткосрочные проекты, а не долгосрочные показатели прогресса в достижении миссии.
У команды, разрабатывающей продукт для клиентов, все немного проще. Например, команда Twilio SMS знала, что их клиентами являются другие разработчики и компании, в которых они работают. Таким образом, их миссия состояла в том, чтобы быть «ведущим глобальным API обмена сообщениями, которому доверяют разработчики и предприятия по всему миру», а основными показателями успеха были доход, количество клиентов, время безотказной работы API и задержка, а также уровень лояльности клиентов.
При наличии четкого определения клиента, ясной миссии и показателей успеха команда настраивается на выполнение миссии, движимая внутренней мотивацией. Эти три аспекта не выдумка руководителей в зале заседаний, их определяет сама команда и, как следствие, считает собственными.
Еще одно преимущество небольшой, мотивированной команды: никто не может спрятаться. Если вы винтик в механизме или один из десятков или сотен участников проекта, то нередко кажется, что ваш вклад не имеет значения, и это плохо сказывается на моральном духе и не позволяет в полной мере использовать навыки и таланты каждого сотрудника. Это также облегчает существование для отстающего исполнителя или любителя отлынивать. Но в небольшой команде из 5–10 человек ни то, ни другое невозможно. У каждого есть важная роль и мало возможности уклониться от активного участия в общем деле.
Определение клиента, миссии и показателей является основой работы небольшой команды.
Клеточное деление
По мере роста бизнеса растет и ваша команда. Как же сохранить команды маленькими в процессе масштабирования бизнеса? Когда появляется новая инициатива, а у вас на каждую команду приходится по одному продукту, ответ прост — финансируйте небольшую команду, созданную для решения новой проблемы. Но когда у вас есть продукт, который требует роста размера команды и масштаба деятельности, то как поступить тогда? Например, наша команда Twilio SMS поначалу, в 2010 г., представляла собой один небольшой коллектив, но теперь состоит из сотен инженеров. Как мы масштабировали ее? Ответ — путем клеточного деления.
Вначале команда совсем небольшая, скажем, пять человек. Когда она разрастается примерно до 10 человек, мы начинаем продумывать ее разделение надвое. Как правило, сложным моментом является то, как именно разделить команду, — подход зависит от ситуации. Иногда деление происходит по функциям продукта, иногда по уровням функциональности, иногда по потребительским сегментам — главное, сохранить клиента, миссию, показатели и базу исходного кода за командой. База исходного кода — самый сложный компонент, поскольку он планируется заранее. Чаще всего существует одна большая база кода, и для того, чтобы разделить команды, нужно разбить ее на две части, которыми две команды могут владеть независимо. Это требует времени — обычно разделение команды планируется как минимум за полгода. Положительная сторона этого процесса заключается в том, что вы постоянно инвестируете в свою кодовую базу, делите ее на микросервисы и исправляете прежние ошибки. Это похоже на весеннюю генеральную уборку, которая очень полезна, когда команда и продукт быстро растут. В результате база исходного кода постоянно приводится в соответствие с тем, что делают команды, которые, в свою очередь, согласуют направления своей деятельности с потребностями клиентов.
Вот пример: Twilio Voice начинался с одной команды. Но когда команда выросла до 15 человек, стало ясно, что она слишком велика и пришло время разделить ее. У этого продукта было два основных аспекта: подключение к телефонным сетям мира и API, выстроенные поверх подключения и позволяющие клиентам организовывать динамические взаимодействия, такие как надиктовывание текста, воспроизведение аудиозаписей и конференц-связь. На уровне подключения клиентам нужны такие функции, как глобальная связь и экономическая эффективность, а на уровне API — конференц-связь, масштабируемая до сотен человек, и более реалистично звучащий голос при преобразовании текста в речь. Это был естественный путь разделения продукта между двумя командами. Мы назвали их командами Voice Connectivity и Programmable Voice. В результате нам пришлось разделить код между этими двумя частями голосового продукта Twilio, и такой подход позволил нам гораздо быстрее подключать и тестировать новых операторов и масштабировать наши дата-центры по всему миру. Скорость разработки функционала также повысилась, поскольку командам больше не нужно было беспокоиться о взаимных соединениях операторов. А затем, когда команда Voice Connectivity сосредоточилась исключительно на потребностях клиентов, ее члены поняли, что сама связь может быть независимым продуктом. В 2014 г. эта команда запустила новый продукт под названием Twilio Elastic SIP Trunking, которым теперь пользуются более 6000 клиентов независимо от продукта Programmable Voice. Таким образом, разделение команды не только привело к переосмыслению архитектуры продукта, но и позволило нашим командам независимо друг от друга сосредоточиться на соответствующих потребностях клиентов, а также создать новый поток доходов для компании.
Однопоточные лидеры и упрощенное принятие решений
Последняя и, пожалуй, самая важная часть масштабирования небольших команд — это, как и следует ожидать, подбор руководителей. Если вам нужна небольшая команда, члены которой сосредоточены на миссии, имеют право принимать трудные решения и нацелены на быстрое обслуживание клиентов, то стиль работы руководителя имеет решающее значение. Мы называем таких лидеров «однопоточные», поскольку они просыпаются утром с одной мыслью — как привести команду к победе. (Поток — это цепочка выполняемых задач в компьютерной программе. Многопоточная программа делает многое одновременно, а однопоточная сконцентрирована на выполнении чего-то одного.) Это может показаться очевидным, однако большинство корпоративных структур такого положения дел не обеспечивают. Чаще всего все продукты и технологические разработки находятся под началом одного руководителя высшего звена компании, возможно, вице-президента. Именно этот руководитель в конечном счете принимает ключевые решения, которые влияют на команды разработчиков, а затем эти разработчики встраивают поставленные цели в свои планы. Другой распространенный подход к управлению небольшой командой — руководство типа «двое в коробке», осуществляемое, как правило, менеджером по продукту и техническим директором. Например, так работает Google. Однако в этом случае непонятно, кто несет ответственность, и никто не может разорвать связку ради прогресса. В стартапе может быть несколько основателей и членов команды, но генеральный директор один, и именно он в конечном счете отвечает за работу.
Многие компании ведут разговоры о делегировании полномочий, но слишком боятся идти на риск, чтобы дать своим лидерам достаточно свободы. Топ-менеджеры слишком озабочены собственным успехом, чтобы позволить подчиненным действовать самостоятельно. Мы говорим о делегировании полномочий, но затем критикуем наши команды задним числом. Руководитель нередко задается вопросом: «Ну как я дам этим командам полномочия и позволю им действовать самостоятельно, когда на кону стоит разве что не моя жизнь? Разве я могу смириться с плохим решением, принятым моей командой? Разве у меня есть возможность отойти в сторону и позволить командам работать самостоятельно?»
Эта проблема существовала и в Twilio, когда у нас были вице-президенты по технологии и продуктам. Они либо слишком вмешивались в работу, отменяя решения команд и, по сути, лишая их самостоятельности, либо, наоборот, сидели в стороне и ничего не делали — ведь у команд есть полномочия и они могут делать все, что считают нужным. Очевидно, ни то ни другое не является идеальным.
Я инструктировал их следующим образом: «Смотрите, я генеральный директор публичной компании и поэтому отчитываюсь перед советом директоров и инвесторами». Если у нас хороший квартал, я распространяю успех на всех, а если плохой квартал, то не говорю: «Это вина директора по продукту, он принял плохое решение, вы должны разбираться с ним». Понятно, что за финансовые результаты, которые публикует компания, отвечаю я. А раз так, то в качестве способа их улучшения я ставлю во главе команд однопоточных лидеров, которые получают полномочия и обеспечивают решение проблем. Лучшее, что вы можете сделать, — научить персонал прислушиваться к клиентам и принимать правильные решения. Я уверен, что так мне удастся достичь моей цели, но на деле, конечно, я по-прежнему должен держать все под контролем.
Конечно, бывают не очень удачные решения, но нужно всегда взвешивать стоимость их отмены и потери доверия к лидерам, прежде чем давать и зеленый свет. Если это решение уничтожит компанию или нанесет долгосрочный вред клиентам, то вам следует вмешаться в процесс. Проблема в том, что лидеры часто принимают несущественные и непоследовательные решения. Это называют «строительство велосипедного навеса».
Строительство велосипедного навеса — одна из моделей поведения руководителей и менеджеров, которая раздражает команды, — это любопытный термин. Вот его происхождение. Представьте, что вы входите в правительственный комитет, отвечающий за строительство ядерного реактора. Инженеры приходят в комитет за решением о том, какой реактор строить: водо-водяной, кипящий или графитовый. Они предлагают вам экспертные заключения и рекомендации. Поскольку вы не эксперт в проектировании ядерных реакторов, то вряд ли станете углубляться в детали и, скорее всего, примете рекомендации опытных инженеров. Однако, если вас спросят, в какой цвет покрасить велосипедный навес около ядерного реактора, начнется большая дискуссия, и каждый член комитета постарается высказать собственное мнение. Иначе говоря, строительство велосипедного навеса — это склонность неспециалистов тратить много энергии на обсуждение незначительных деталей, поскольку у них нет знаний для принятия важных решений.
Тем не менее лидеры обычно стремятся передать вопрос наверх. В какой-то мере это проверка правильности решений, но в случае трудных вопросов проще попросить босса принять решение. Однако это уход от ответственности, что не очень хорошо для формирования корпоративной культуры наделенных полномочиями лидеров. Как руководитель, я больше задаю вопросы, нежели отвечаю на них. Моя цель — сделать ответственными однопоточных лидеров, но при этом помочь им найти ответы на свои собственные вопросы. Я не идеален и слишком часто иду на поводу и принимаю решение сам, но моя цель — помочь лидерам найти собственные решения.
Без однопоточных лидеров, наделенных правом принимать решения, компании обращаются к другим схемам принятия решений, которые, на мой взгляд, менее эффективны. Возможно, вы слышали о модели принятия решений RAPID© — это одна из многих систем, которые помогают организациям понять, «у кого есть D», т.е. решение. RAPID© была создана компанией Bain как инструмент для уточнения ответственности за принятие решений, выделяющий пять ключевых ролей (рекомендация, согласование, осуществление, предоставление информации и принятие решения).
В Twilio мы пробовали использовать RAPID© в некоторых подразделениях, но поняли, что эффективность падает, когда в модели появляется еще одна роль «без речи» — V (вето). Вы можете согласиться с процессом RAPID© в целом, но если есть менеджер, который может наложить вето, то человек, который теоретически имеет право принимать решения, на деле лишается его. Это прямая противоположность наделению полномочиями однопоточного лидера. Вы говорите, что у него есть право принимать решения, но если вы пересматриваете решения или, что хуже, накладываете на них вето, то это право существует лишь на словах. Лидер будет бояться принимать решения и передавать большую часть дел вам. На мой взгляд, это прямой путь к уничтожению внутренней мотивации.
Так какой же выход? Люди чувствуют себя полноценными работниками в зависимости от того, насколько они близки к лицу, принимающему решения. Из этого следует:
- Если вы принимаете решения, то вы полностью самостоятельны.
- Если у вашего менеджера есть решение, то вы понимаете, как оно принимается, помогаете принять его и поддерживаете.
- Если затрагивающее вас решение принимает тот, кого вы редко видите или даже не знаете, то вы чувствуете себя жертвой. Это делается в отношении вас, а не вместе с вами. Вы начинаете считать себя пассивной частью процесса, в отличие от уполномоченного и облеченного доверием лица.
Небольшие команды и однопоточные лидеры, руководящие ими, помогают свести к минимуму вероятность того, что люди окажутся в третьей позиции — в роли бесправных жертв решений, с которыми они не согласны.
Ловушка улучшения сотрудничества
Одна из проблем, которая быстро проявляется при масштабировании небольших самостоятельных команд, связана с координацией их работы. Чем больше команд и чем более они самостоятельны, тем меньше у них шансов на сотрудничество, если судить по жалобам руководства. На самом деле, когда в компании что-то не ладится, руководители обычно заявляют: «Нам нужно улучшить сотрудничество». И хотя это звучит неплохо, несерьезно говорить, что людям просто нужно лучше управлять тысячами своих взаимосвязей с другими людьми и командами. Никакая система не справится с такой нагрузкой. Неудивительно, что количество деловых встреч растет, а большинство сотрудников просто присутствуют на них.
Это я и называю «ловушка улучшения сотрудничества».
Небольшие команды потенциально меньше нуждаются в сотрудничестве — как и стартап, они идеально приспособлены к тому, чтобы сконцентрировать внимание на клиенте и небольшом количестве людей, связанных с их миссией. Но, конечно, команды должны взаимодействовать друг с другом, чтобы добиться значимых результатов.
Поэтому важно формализовать отношения между командами в виде «контрактов на обслуживание». Смотрите на команды как на независимые стартапы — когда вы ведете с ними дела, их продукт четко определен, а ценообразование понятно. Представьте сайт другой команды, описывающий ее продукты, с виртуальной кнопкой «Связаться с нами» или «Начать работу», если вам нужен какой-то продукт. При взаимодействии через корпоративные границы такие формализованные контракты необходимы — продукт должен иметь описание, цена должна быть согласована, но внутри компании все по-другому. Если каждая команда предоставит другим формализованное описание «Вот что мы делаем, и вот как с нами взаимодействовать», то стоимость координации снизится. Это способ стандартизации взаимодействия, превращения его в хорошо понятный и масштабируемый процесс. Можно даже поставить цены на услуги, чтобы помочь с внутренним учетом и планированием ресурсов.
В технологических командах такими интерфейсами обычно являются API и хорошая документация. Когда команде Programmable Voice нужно куда-то позвонить, они делают запрос через API на уровень Voice Connectivity. Такой четко определенный контракт на обслуживание между командами обеспечивает стабильный, предсказуемый и задокументированный способ взаимодействия и даже предусматривает выставление счетов за предоставленные услуги. Подобная практика не ограничивается технологическими командами. В других подразделениях организации можно применять аналогичные принципы взаимодействия. Например, ваша юридическая команда тратит много времени на переговоры о контрактах с клиентами вместе с командой продаж, но есть ли у них четкий «API» для взаимодействия? Как заключается новый контракт? Как отслеживается прогресс в работе? Сколько «стоит» нанять штатного адвоката и учитывается ли это в себестоимости продаж? Представьте себе юридическую команду с платформой самообслуживания, где продажники могут взять утвержденные заготовки, не требующие участия адвоката. Это был бы отличный продукт! Многим продажникам это должно понравиться, поскольку такая платформа ускоряет цикл заключения сделок и требует меньше «сотрудничества» с юридической командой.
Вот еще один хороший пример: несколько лет назад в наших офисах появился торговый автомат, битком набитый клавиатурами, мышами, адаптерами питания для ноутбуков и т.п. Вместо внесения денег вы сканируете свой бейдж и получаете необходимое вам оборудование (которое отслеживается в целях бухгалтерского учета и бережливого использования). Это своего рода контракт нашей ИТ-команды на обслуживание сотрудников. Для исключения бесконечных походов сотрудников в ИТ-службу для получения аппаратного ключа или клавиатуры был создан четкий интерфейс (торговый автомат), процесс (отсканируйте бейдж, и получите мышь) и даже ценник. Это новый способ взаимодействия команд со стандартным интерфейсом для совместной работы.
При доведении такой организации до логического конца каждая внутренняя команда получает возможность выбрать «продукт» другой команды или даже обратиться к внешнему поставщику с таким же, но более дешевым сервисом, с более полным набором функций или с более качественным обслуживанием. Когда у всех есть удобные интерфейсы, команды могут выбирать лучший инструмент для работы и втягиваются в соревнование за «завоевание» внутренних клиентов. Для того чтобы команда выбрала внешний вариант, необходимо выполнить определенные условия, такие как соблюдение минимальных пороговых уровней безопасности или надежности. Но если условия соблюдаются, то команды получают больше самостоятельности в обслуживании клиентов. Вот почему важно включать экономический аспект в интерфейс. Без внутреннего ценника он выглядит «бесплатным», хотя на самом деле цена существует. Если вы хотите, чтобы небольшая команда действовала как стартап, то наличие «дохода» в качестве показателя успеха значительно проясняет ситуацию. В противном случае увеличение числа команд, зависящих от вас, будет означать просто более значительный объем работы, а не успех.
Это реально позволяет командам думать о результате своей работы как о продукте, предназначенном для обслуживания клиентов, точно так же, как и при обслуживании потребителей за пределами компании. У коммерческой юридической команды продукт — это оформление контрактов, которые защищают компанию, но позволяют ей расти, а клиенты — это команда по продажам и конечные покупатели. Если вы можете разработать способ обслуживания этих клиентов и быстрее находить пути его улучшения, то это программный подход к решению проблемы, а не затыкание дыр за счет увеличения числа работников. Не забывайте, что с ростом численности усложняется взаимодействие.
На мой взгляд, цель компании — это не улучшение сотрудничества, а его сокращение. Выдающиеся компании не говорят: «Нам нужно улучшить поддержку клиентов». Они говорят: «Нам необходимо уменьшить потребность клиентов в обращении в службу поддержки». Аналогичным образом выдающиеся компании уменьшают потребность команд и людей в сотрудничестве, стандартизируя или превращая взаимодействия между группами в продукт. Это позволяет командам тратить больше времени на инновации и меньше времени — на внутренние координационные совещания. Главное — относиться к другим подразделениям компании как к клиентам, а не как к коллегам по работе.
Stripe Atlas: создайте команду, похожую на единый мозговой центр
Помните Patio11, с которым вы познакомились в главе 4? У него есть отличный образ для описания того, на что похоже построение успешной небольшой команды: создание единого мозгового центра, включающего все необходимые функции. Такой подход помогает избежать того, что, по его мнению, является главной проблемой многих компаний (хотя это стандартная практика): изоляции разработчиков от бизнес-процессов. По его словам, «это проблема организационной структуры во многих отношениях. Обычно компании говорят: “Ничего, что у нас бизнес-подразделение здесь, а инженерная команда в другом месте — у них ведь есть интерфейс”». Под «интерфейсом», к которому он относится скептически, понимаются требования к продукту, канбан-доска или другие системы вывешивания рабочих задач на стене. На деле это часто приводит к конфронтации, поскольку программисты составляют график и выполняют работу, а потом, как это всегда бывает, требования меняются. И тогда начинаются взаимные обвинения. По словам Patio11, «те, кто работал над ПО, говорят: “Вы меняете правила игры для меня, мне приходится выбрасывать сделанную работу. У меня теперь летят все сроки. Эти тупицы в бизнес-подразделении не понимают, как пишутся программы”. А бизнесмены говорят: “Эти тупые разработчики обещали, что система будет готова к марту. На дворе февраль, а мы даже не приблизились к завершению разработки системы”».
Подводя итог, он заключает: «Разработчики — на Марсе, те, кто составляет требования, — на Венере, и они никогда не встретятся». Такая структура и ее предсказуемый результат возникают в каждой компании, где решили отделить тех, кто создает продукт, от тех, кто понимает, что именно требуется создать.
Так быть не должно. Здесь на сцену выходят небольшие кросс-функциональные команды.
Компания Stripe, где работает Patio11, давно научилась объединять разработчиков и бизнесменов в одну команду для выполнения проектов. Но при создании команды для разработки приложения Atlas — продукта, который позволяет предпринимателям зарегистрировать корпорацию в штате Делавэр с помощью всего нескольких кликов, — они пошли еще дальше в плане объединения функций. Для этого проекта они свели в одну команду не только разработчиков и бизнесменов, но и службу по работе с клиентами, юридическую службу и маркетинг. Мало того, они посадили всех в одной комнате.
Это дает огромные преимущества, в частности, повышает эффективность. Patio11 так описывает один из результатов: «Юрист Atlas сидел рядом с командой инженеров. Юридический аспект был очень важен для этого продукта. Когда кто-то приходил в 11:00 с вопросом вроде “Я не уверен, что эта скопированная часть кода у меня на экране в порядке”, они могли буквально повернуться к юристу и сказать: “Слушай, законность копирования — это твой вопрос. Можно мне сделать то-то и то-то?”, а тот отвечал: “Стоп. Зачем вообще делать это? Нельзя ли подойти к этому фрагменту по-другому?”» А потом они за пять минут придумывали оптимальный подход.
Сравните это с обычным процессом, когда разработчик занимается программой 12 недель, и только после этого проект поступает на рассмотрение. В этот момент, как объясняет Patio11, «уже невозможно изменить предположения, которые легли в основу целого ряда экранов и обмена данными между ними. Вы заперты в рамках уже готового продукта, и все, что можно сделать, — попытаться решить проблему плохого понимания правовой среды подбором формулировок на экранах». Вот почему объединение всех специалистов в одну команду и даже устранение физической и организационной дистанции между ними является столь действенным инструментом. Такая организация позволяет отфильтровать неправильные предположения и плохие решения в самом начале процесса.
Кроме того, это удивительным образом сказывается на моральном духе коллектива. Все в команде Atlas идентифицируют себя прежде всего как члены команды, а не просто как работники. Представляясь, вам говорят не «Меня зовут Сюзан, я работаю в команде поддержки пользователей над проектом Atlas», а «Меня зовут Сюзан, я работаю в команде Atlas, которая занимается поддержкой пользователей». Проще говоря, подчеркивают принадлежность не к компании Stripe и службе поддержки пользователей, а к команде Atlas. Служба поддержки пользователей — то самое место, где компании нередко разъединяют тех, кто работает с клиентами, и команду, создающую продукт. Это приводит к тому, что люди начинают думать о себе как о винтиках в машине. «Они видят, что работа здесь — это получил задание, выполнил задание. Через некоторое время такое отношение надоедает, что выливается в высокую текучесть кадров», — объясняет Patio11.
В команде Atlas все совершенно не так. Люди настолько привязываются к ней, что отказываются от перехода в другие отделы, даже если это открывает возможности для роста. Более того, они чувствуют аналогичную связь и с клиентами, добиваясь такого взаимодействия, которого, как говорит Patio11, «он не видел ни в одной другой команде».
Налаженная обратная связь и кросс-функциональность команды Atlas позволяют разработчикам делать именно то, что хотят клиенты, причем почти мгновенно. Вот всего один пример. Сначала приложение Atlas предназначалось исключительно для того, чтобы помочь стартапам зарегистрироваться, обычно в штате Делавэр. Это было здорово, однако понятно, что регистрация лишь первый шаг в сложном взаимодействии с правительством при создании компании. Поэтому клиенты начали обращаться к Atlas за помощью в других областях, где они сталкивались с бюрократией, которая отнимает массу сил у предпринимателей.
В ноябре 2017 г., когда с момента запуска Atlas прошел примерно год, на очередном совещании команды поддержки пользователей разговор пошел о том, почему внезапно вырос поток вопросов клиентов о налогах. Patio11 поинтересовался, о каких налогах они спрашивают, — известно, что компании платят налог с продаж, налог на прибыль, налог на заработную плату и т.д., — и услышал в ответ: «О чем-то под названием “франшизный налог”».
Как опытный предприниматель, Patio11 сразу же вспомнил сложность расчета годового франшизного налога в штате Делавэр, который должна платить каждая компания. Понятно, что шквал вопросов обрушивается на разработчиков в тот момент, когда Департамент налогообложения франшиз штата Делавэр (опять этот ужасный департамент!) начинает рассылать компаниям свои ежегодные напоминания о наступлении срока уплаты налога. Пользователи обращались за помощью к Atlas, обещавшему помогать им во всех сложных ситуациях.
Прежде всего команда создала на скорую руку функцию помощи клиентам и таким образом избавила их от новых обращений за помощью. «Мы встроили новую функцию в панель задач, помогающую с оплатой франшизного налога штата Делавэр, но каждый должен рассчитывать его самостоятельно в соответствии с инструкциями штата Делавэр, которые нельзя назвать простыми».
Только представьте, насколько заманчиво решить очередную проблему своих клиентов — фактически заполнить налоговую декларацию, избавив от необходимости возиться с невразумительным сайтом штата Делавэр. Сначала инженеры инстинктивно ответили: «Налоги выходят за рамки нашей компетенции». Однако Patio11, как лидер, увидел здесь скрытую возможность. У миллиона компаний уходит по два часа в год на заполнение налоговой декларации в штате Делавэр, и если команда Atlas потратит несколько недель на создание соответствующий функции, то она сэкономит миллионы часов рабочего времени для них и, по сути, сделает человечество более эффективным.
Patio11 уже не раз составлял налоговые декларации и съел собаку на них, поэтому он мог описать программу, которая упростила бы этот процесс для клиентов. Впрочем, существовала одна закавыка. Полуавтоматическое заполнение форм клиентами могло оказаться проблематичным из-за наличия двух способов расчета налога: способа A и способа B. В принципе, стартапы всегда должны использовать способ B. Разработчики Atlas задались вопросом, можно ли рекомендовать клиентам сразу перейти к способу B, но юристы в команде полагали, что подобное слишком близко к юридической консультации. Инженеры предложили компромисс: программа по умолчанию предлагает способ B, но предупреждает о том, что если юрисконсульт рекомендует использовать способ A, то нужно обращаться непосредственно в администрацию штата Делавэр. Такое предложение устроило команду юристов.
Таким образом, разработчики взяли непредвиденную потребность клиента, превратили ее в юридически сложное решение, которое экономило клиентам массу времени, и согласовали его с командой юристов. Если бы юрист не был в одной комнате с командой, он мог бы ответить: «Нет, о чем вообще речь? Мы не можем давать клиентам юридические консультации». Однако он вник в проблему и взялся решать ее вместе со всеми. При таком подходе удалось быстро начать работу над программой и создать ее к моменту подачи налоговых деклараций.
Инженеры разработали функцию расчета налогов, причем достаточно быстро, чтобы включить ее в следующую версию Atlas. Программа рассылает клиентам напоминания о необходимости уплаты налогов и помогает определить их сумму. Процесс, который раньше отнимал два-три часа, теперь занимает меньше минуты. «Мы здорово поработали, но этого не произошло бы, если бы представитель службы поддержки клиентов не сказал тогда на совещании: “Срок уплаты налогов прошел полгода назад, и клиенты уже спрашивают о наших планах”», — вспоминает Patio11.
Этого не произошло бы, если бы инженеры из команды Atlas были изолированы от остальных. Подобное удалось потому, что команда находилась в одном вместе и все участвовали в принятии решений. У инженеров нет собственных специальных совещаний, а вот у маркетологов, специалистов по работе с клиентами и юристов они есть. Но когда собирается команда Atlas, в совещаниях принимают участие все. Таким образом, никто не отрывается от клиентов и может дать им все необходимое. Они — единый мозговой центр, обслуживающий клиентов.
Команды работают наиболее эффективно, когда каждый их член чувствует ответственность перед клиентом и глубоко осознает необходимость его обслуживания. Небольшие команды обеспечивают существование такой связи, нацеленности и миссии, которая рождается внутри команды под влиянием прежде всего взаимодействия с клиентом и знания его проблем, а не спускается сверху.
Итак, вам нужно, чтобы члены команды и команда в целом верили в важность своего дела. Эта внутренняя мотивация возникает не вследствие вдохновляющих речей или большой зарплаты. Она — результат знания того, что ваша работа оказывает реальное влияние на жизнь людей.
В большинстве компаний директивы движутся через организационную структуру сверху вниз. Но в Twilio, Stripe и других компаниях, верящих в небольшие команды, все наоборот. Собеседники — а это часто инвесторы — спрашивают меня, почему мы даем так много самостоятельности небольшим командам, позволяем им самим определять приоритеты и планы действий. Я отвечаю: «Кто лучше них знает, как обслуживать клиентов? Я сижу здесь и разговариваю с инвесторами, а они общаются с клиентами. Как вы думаете, кто знает больше о том, что мы должны сделать для наших клиентов?»
На мой взгляд, главная цель небольших кросс-функциональных команд и однопоточных лидеров состоит в том, чтобы команды чувствовали клиента, отвечали за принимаемые решения и знали, что их работа напрямую конвертируется в прогресс. Чтобы понять, как чувствуют себя ваши команды, можете поинтересоваться у их членов, как принимаются решения. Например, спросите своих разработчиков, кто принимал одно из последних решений и участвовали ли они в этом процессе? Когда решение было принято, даже в случае несогласия подчинились ли они и действовали ли далее как единая команда? Вы можете спросить, от чего больше зависят решения — от потребностей клиентов или от указаний сверху? Чтобы понять, чувствует ли команда ответственность за прогресс, спросите, какими показателями она пользуется и может ли контролировать эти показатели. Спросите, сколько людей за пределами команды решают, что она может или не может делать. Ответы на эти вопросы должны дать вам представление о чувстве ответственности и внутренней мотивации команды. Спросите лидеров, когда им удается или не удается решить задачу, чувствуют ли они, что успех или неудача в значительной мере зависит от них? Если ответ «нет», подумайте, как организовать команды таким образом, чтобы каждый чувствовал себя ответственным за решения и результаты. В противном случае люди будут уходить из компании.
