Эффективная работа в масштабе

Брайан Армстронг, генеральный директор и соучредитель

По мере масштабирования компании обычно замедляются и становятся менее эффективными. Требуется больше долларов, больше людей и больше времени, чтобы что-то сделать. Координационные препятствия усиливаются, возникают ветократии, терпимость к риску ослабевает, и команды становятся сосредоточенными на себе, вместо того чтобы оставаться сосредоточенными на своих клиентах.

Хотя эта траектория естественна, она не является неизбежной. Каждая великая компания, от Amazon до Meta и Tesla, нашла способы сохранить свою энергию основания в сочетании с соответствующими средствами контроля, даже когда они стали намного больше, чем Coinbase сегодня. Великие компании сохраняют свое бунтарское мышление, опасаясь со временем стать самодовольными и бесполезными.

Вот почему мы сосредоточены на повышении эффективности Coinbase. После 18 месяцев роста сотрудников примерно на 200% в годовом исчислении многие из наших внутренних инструментов и организационных принципов начали напрягаться или ломаться. Итак, мы копались, чтобы определить набор изменений, которые нам необходимо внести, чтобы помочь нам добиться успеха в этом новом масштабе.

Первым шагом было значительное замедление нашего роста и принятие трудного решения сократить размер нашей нынешней команды, которую мы объявлено в прошлом месяце. Двигаясь вперед, мы продолжим искать способы сделать Coinbase более эффективным и вернуться к мышлению и подходу, которые сделали нас успешными. Я верю, что эти шаги поведут нас вперед.

Мы используем DRI (непосредственно ответственных лиц), чтобы помочь нам работать быстрее. DRI уравновешивают вклад команды и своевременно принимают четкие решения.

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

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

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

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

Хотя руководители продуктов могут действовать независимо друг от друга, продукты часто имеют общие элементы. У нас есть общие услуги, связанные с тем, как клиенты подключаются к системе, управляют своими учетными записями, хранят криптовалюту, добавляют способы оплаты, обменивают криптовалюту и многое другое. При неправильном использовании общие сервисы могут замедлить работу и разочаровать команды разработчиков. Но когда они хорошо работают, они могут создать удивительную синергию между продуктами и более глубокую интеграцию продуктов.

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

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

Мы начинаем развертывать новую концепцию, которую мы называем «модули», чтобы создать больше структуры вокруг соответствующего размера команды. В рамках каждого продукта мы будем определять группы из <10 человек, работающих над определенной функцией или областью. Если группа вырастет до более чем 10 человек, пришло время разделить ее на две части и назначить каждому более конкретную цель или направление. Поды также должны иметь фокус и метрику полярной звезды, которая связана с общими показателями компании.

Внутри растущих компаний существует опасность, что команды разработчиков и разработчиков начнут выпускать великолепные слайды вместо отличных продуктов. Может быть заманчиво «управиться» и почувствовать, что встреча прошла отлично, когда начальству показали красивую колоду. Но наши клиенты никогда не видят слайды, которые мы создаем. Они видят только продукт.

Поэтому мы экспериментируем с запретом слайдов в обзорах продуктов и инженеров. Вместо слайдов можно показать:

• Панель инструментов с вашими показателями — надеюсь, ваша команда в любом случае просматривает ее хотя бы раз в неделю.
• Мокапы Figma
• Но самое главное… покажите сам продукт и используйте его вживую!

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

Делая это, мы не должны тратить слишком много времени на разговоры о том, что на собраниях идет хорошо. Мы можем поделиться тем, что идет хорошо, на предварительном чтении и воспользоваться моментом, чтобы отметить это, но большую часть времени на встречах следует сосредоточить на том, что идет не так, чтобы мы могли улучшить продукт.

Трудно переоценить этот момент. Внутри компаний есть много вещей, которые кажутся работой, но в конечном итоге не улучшают качество обслуживания клиентов — от рыночных циклов и негативной прессы до политических усилий, внутренней политики/драмы, титулов и компенсаций. У нас есть команды, которые сосредоточены на этих областях, поэтому подавляющее большинство сотрудников компании (более 80%) могут по-прежнему сосредоточиться на общении с клиентами и создании более качественных продуктов.

Более крупные компании также замедляются из-за бесконечных совещаний по поводу определения приоритетов и запросов функций. Нам нужно перейти к модели, в которой все команды разработчиков продуктов и инженеров (а не только общие службы) публикуют API, чтобы другие команды могли извлечь выгоду из того, что они создают. без необходимости планировать встречу. Другими словами, им необходимо сделать свои услуги продуктом и позволить другим командам использовать их в режиме самообслуживания.

Это требует от нас внедрения внутреннего каталога API, в котором любой инженер Coinbase может найти подходящую услугу. Без этого любому инженеру трудно даже узнать, существует ли API, что приводит к дублированию работы. Все сервисы должны быть спроектированы с использованием «мощеных дорог», что означает согласованные библиотеки и языки для аутентификации, ведения журналов, инструментовки и т. д. Многие из этих API-интерфейсов также будут доступны в Coinbase Cloud для внешних клиентов, что сделает их еще более надежными.

В конечном счете, многое из этого сводится к сохранению менталитета основателя внутри компании и действиям собственника. Большинство компаний начинают с того, что выступают против истеблишмента, пытаясь исправить что-то неправильное в мире. Но по мере того, как они становятся больше и успешнее, они начинают становиться новым истеблишментом. Они успокаиваются, ощущение, что они выиграли, и начинается бюрократия.

В Coinbase одна из наших ценностей — повторяемые инновации, а это означает, что мы всегда хотим расширять границы возможного. Мы используем модель распределения ресурсов 70/20/10, при которой мы инвестируем 70% наших ресурсов в наш основной бизнес и 20% в стратегические усилия, мы также гарантируем, что 10% наших ресурсов всегда идут на амбициозные новые ставки. И мы всегда стараемся создавать продукты, которые пользуются наибольшим доверием и просты в использовании, чтобы мы могли привлечь миллиард человек в криптовалюту. Это лучший способ выполнить нашу миссию по увеличению экономической свободы в мире.

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

Компании подходят к этой проблеме снижения эффективности по-разному, в зависимости от ситуации. Мы договорились о внедрении этих изменений и инструментов после тщательного исследования того, как другие компании справились с этим. Вот несколько замечательных книг и ресурсов, которые помогли мне в изучении этой темы:

• Усильте это: Фрэнк Слутман отлично блоге на этом, что превратилось в книгу. Основная идея заключается в том, что когда кто-то говорит, что я свяжусь с вами на следующей неделе, скажите, как насчет завтра. Когда кто-то говорит, что это займет шесть месяцев, спросите, как бы мы сделали это за шесть недель или шесть дней, если бы нам пришлось.
• Развернуть корабль: Основная идея этой книги заключается в том, что вместо того, чтобы спрашивать своего руководителя, что вам следует делать, скажите ему или ей, что вы намереваться сделать, и они отредактируют ваше мышление, если это необходимо. Вам все еще нужно сообщить, но это ваша ответственность выбрать лучший путь.
• Менталитет основателей: Основная идея состоит в том, чтобы поддерживать повстанческий образ мышления с упором на действие, смелую миссию, защиту интересов клиентов и многое другое. Попробуйте викторина Больше подробностей.
• Координация: Масштабируемые организации должны быть слабо связанными и тесно связанными. Другими словами, согласуйте миссию, ценности и показатели высокого уровня, а затем дайте лидерам возможность выбирать свой собственный путь с более локализованным принятием решений.