Брайан Армстронг, генеральный директор и соучредитель
По мере масштабирования компании обычно замедляются и становятся менее эффективными. Требуется больше долларов, больше людей и больше времени, чтобы что-то сделать. Препятствия координированию усиливаются, возникают силы ветократии, терпимость к риску ослабевает, а команды сосредотачиваются на себе, вместо того чтобы оставаться сосредоточенными на своих клиентах.
Хотя эта траектория естественна, она не неизбежна. Каждая великая компания, от Amazon до Meta и Tesla, нашла способы сохранить свою энергию основания в сочетании с соответствующими средствами контроля, даже когда они стали намного больше, чем Coinbase сегодня. Великие компании сохраняют свое бунтарское мышление, опасаясь со временем стать самодовольными и бесполезными.
Вот почему мы сосредоточены на повышении эффективности Coinbase. После 18 месяцев роста сотрудников примерно на 200% в годовом исчислении многие из наших внутренних инструментов и организационных принципов начали напрягаться или ломаться. Поэтому мы тщательно изучили ряд изменений, которые нам необходимо внести, чтобы добиться успеха в этом новом масштабе.
Первым шагом было значительное замедление нашего роста и принятие трудного решения о сокращении размер нашей нынешней команды, о которой мы объявили в прошлом месяце. Двигаясь вперед, мы продолжим искать способы сделать Coinbase более эффективным и вернуться к мышлению и подходу, которые сделали нас успешными. Я верю, что эти шаги помогут нам продвинуться вперед.
Перенесите принятие решений на однопоточные DRI
Мы используем DRI (непосредственно ответственных лиц), чтобы ускорить работу. DRI уравновешивают вклад команды и своевременно принимают четкие решения.
Но теперь, когда мы стали крупной компанией со многими продуктами, а не с одним, нам нужно скорректировать то, как мы принимаем решения — принятия решений внутри организации, устранения узких мест и расширения возможностей наших руководителей продуктов.
У DRI часто возникает искушение протолкнуть решения, составляющие цепочку, когда они не уверены или не хотят рисковать. Иногда они боятся быть уволенными, если решение не будет успешным. Вот почему, где это возможно, мы все больше внимания уделяем выявлению «однопоточных» DRI. Однопоточный — это технический жаргон, который просто означает сосредоточение исключительно на одной области. Однопоточный DRI — это самый старший сотрудник, чья единственная работа заключается в управлении данным продуктом или инициативой. Обычно это руководитель отдела управления продуктом или разработчик. Они не могут быть однопоточными DRI, если они являются DRI для нескольких областей.
Это может означать, что не каждое решение идеально. Но это нормально, если мы сможем масштабировать наше влияние и расширить возможности экспертов в данной области, которые ближе к продуктам и ближе к нашим клиентам.
Предоставить лидерам продуктов возможность видеть свои прибыли и убытки
Каждый из наших продукты имеют хорошо финансируемых конкурентов, которые являются специализированными компаниями. Мы считаем, что правильный способ конкурировать — это стимулировать наших лидеров по производству к тому, чтобы они также управляли своим продуктом как отдельной компанией. Компании должны добиться прибыльного роста в разумные сроки. Со временем мы сможем предоставить руководителям продуктов прямую видимость их прибылей и убытков, чтобы они могли продвигать свой продукт к положительной марже и принимать более правильные решения о том, куда инвестировать, в то время как на уровне руководителей мы продолжим следить за консолидированной производительностью.
Используйте общие сервисы, чтобы свести к минимуму дублирование
Несмотря на то, что руководители продуктов могут работать независимо друг от друга, продукты часто содержат общие элементы. У нас есть общие услуги, связанные с тем, как клиенты подключаются к системе, управляют своими учетными записями, хранят криптовалюту, добавляют способы оплаты, обменивают криптовалюту и многое другое. При неправильном использовании общие сервисы могут замедлить работу и разочаровать команды разработчиков. Но когда они работают хорошо, они могут создать удивительную синергию между продуктами и более глубокую интеграцию продуктов.
Команды, работающие над продуктом, не должны использовать недоделанный общий сервис. Но как только общая служба становится зрелой, может потребоваться, чтобы все продукты использовали ее. Мы обнаружили, что часто бывает полезно запустить общий сервис, имея в виду один основной продукт. Когда становится ясно, что мы дублируем усилия или создаем непоследовательный пользовательский опыт в наших продуктах, сервисы должны превратиться в четко несвязанные сервисы, которые можно использовать в любом продукте.
Организуйте команды в небольшие модули
Небольшие команды более эффективны. Вот почему важно установить максимальный размер для команд, чтобы они не становились слишком большими и не замедлялись .
Мы начинаем внедрять новую концепцию, которую мы называем «модулями», для создания большей структуры. вокруг соответствующего размера команды. Внутри каждого продукта мы будем определять блоки
