Ефективна робота в масштабі

Браян Армстронг, генеральний директор і співзасновник

Коли компанії розширюються, вони зазвичай сповільнюються та стають менш ефективними. Щоб щось зробити, потрібно більше доларів, більше людей і більше часу. Перешкоди координації посилюються, з’являються ветократії, толерантність до ризику зникає, а команди стають зосередженими на собі, замість того, щоб зосереджуватися на своїх клієнтах.

Хоча ця траєкторія є природною, вона не є неминучою. Кожна велика компанія, від 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 завжди ґрунтувався на здатності працювати ефективно з мисленням стартапу. Тепер, коли ми пристосовуємося до нашого нового масштабу, нам потрібно повернутися до речей, які зробили нас успішними — підвищити ефективність і позбутися самовдоволення, яке може проникнути у більшу компанію. Нам потрібно надати нашим керівникам повноваження приймати рішення, а нашим командам – надавати клієнтам чудові продукти. Це буде нелегко, і нам потрібно буде продовжувати пристосовуватися. Але ми зайшли так далеко, і я впевнений, що якщо ми зараз приймемо розумні рішення, це буде лише початок.

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

• Підсилюйте це: у Френка Слотмана чудово блог про це, що перетворилося на книгу. Основне повідомлення полягає в тому, що коли хтось каже, що я зв’яжуся з вами наступного тижня, скажіть, як щодо завтра. Коли хтось каже, що це займе шість місяців, запитайте, як би ми зробили це за шість тижнів або шість днів, якби нам знадобилося.
• Розвернути корабель: Основна ідея цієї книги полягає в тому, що замість того, щоб запитувати свого керівника, що вам робити, скажіть йому чи їй, що ви маєте робити мати намір зробити, і вони відредагують ваше мислення, якщо потрібно. Вам все одно потрібно інформувати, але ви повинні вибрати найкращий шлях.
• Менталітет засновників: Основне повідомлення полягає в підтримці повстанського мислення з упередженістю до дій, сміливою місією, захистом інтересів клієнтів тощо. Спробуйте вікторина для більш докладної інформації.
• Координація Зустрічний вітер: Масштабовані організації мають бути слабко пов’язані та тісно узгоджені. Іншими словами, узгоджуйте місію, цінності та показники високого рівня, а потім дайте лідерам можливість прокладати власний шлях із більш локальним прийняттям рішень.