Мы в 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.