Fungerar effektivt i stor skala

Av Brian Armstrong, VD och medgrundare

När företag skalar upp saktar de oftast ner och blir mindre effektiva. Det tar fler dollar, fler människor och mer tid att få något gjort. Samordningsmotvinden ökar, vetokratier uppstår, risktoleransen avtar och teamen blir inåtriktade istället för att fokusera på sina kunder.

Även om denna bana är naturlig, är den inte oundviklig. Varje bra företag, från Amazon till Meta till Tesla, hittade sätt att behålla sin grundenergi i kombination med lämpliga kontroller, även när de skalade till att vara mycket större än Coinbase är idag. Stora företag behåller sitt upproriska tänkesätt, av rädsla för att bli självbelåtna och irrelevanta med tiden.

Det är därför vi fokuserar på att öka effektiviteten hos Coinbase. Efter 18 månader av ~200 % årlig personaltillväxt har många av våra interna verktyg och organisationsprinciper börjat anstränga sig eller gå sönder. Så vi har grävt i för att identifiera uppsättningen av förändringar vi behöver göra för att hjälpa oss att lyckas i denna nya skala.

Det första steget var att avsevärt bromsa vår tillväxt och fatta det svåra beslutet att minska storleken på vårt nuvarande team, vilket vi meddelade förra månaden. Framåt kommer vi att fortsätta leta efter sätt att göra Coinbase mer effektiv, och för att komma tillbaka till tankesättet och tillvägagångssättet som gjorde oss framgångsrika. Jag tror att dessa steg kommer att föra oss framåt.

Vi använder DRI:er (direkt ansvariga individer) för att hjälpa oss att utföra snabbare. DRI balanserar input från teamet och fattar tydliga beslut i tid.

Men nu när vi är ett större företag med många produkter istället för en, måste vi anpassa hur vi fattar beslut – pressa ner det mesta beslutsfattandet i organisationen, ta bort flaskhalsar och stärka våra produktledare.

DRI:er har ofta frestelsen att driva beslutsfattande upp i kedjan när de inte är säkra eller inte vill ta risker. Ibland är de rädda för att få sparken om beslutet inte går bra. Det är därför vi, där det är möjligt, alltmer fokuserade på att identifiera "entrådiga" DRI. Enkeltrådad är teknisk jargong som helt enkelt betyder enbart fokuserad på ett enda område. Den enkelgängade DRI är den mest seniora personen vars endast jobb är att driva en viss produkt eller ett visst initiativ, detta kommer vanligtvis att vara en produktlednings- eller ingenjörsledare. De kan inte vara entrådiga DRI om de är DRI för flera områden.

Detta kan innebära att inte alla beslut är perfekta. Men det är OK om vi kan skala vår inverkan och stärka ämnesexperter som är närmare produkterna och närmare våra kunder.

Var och en av våra produkter har välfinansierade konkurrenter som är dedikerade företag. Vi tror att det rätta sättet att konkurrera är att uppmuntra våra produktledare att också driva sin produkt mer som ett fristående företag. Företag måste uppnå lönsam tillväxt på någon rimlig tidshorisont. Med tiden kommer vi att kunna ge produktledare direkt insyn i deras P&L, så att de kan flytta sin produkt mot positiva marginaler och fatta bättre beslut om var de ska investera, medan vi på ledningsnivå kommer att fortsätta att titta på konsoliderade resultat.

Medan produktledare kan arbeta självständigt, finns det ofta gemensamma inslag mellan produkter. Vi har delat tjänster kring hur kunder ombord, hanterar sina konton, lagrar krypto, lägger till betalningsmetoder, handlar med krypto och mer. Om du gjort fel kan delade tjänster sakta ner och frustrera produktteam. Men när de fungerar bra kan de skapa fantastiska synergier mellan produkter och djupare produktintegration.

Produktteam bör inte krävas att använda en halvfärdig delad tjänst. Men när en delad tjänst väl är mogen, kan alla produkter behöva använda den. Vi har upptäckt att det ofta hjälper att starta en delad tjänst med en ankarprodukt i åtanke. När det står klart att vi duplicerar ansträngningar eller skapar en inkonsekvent användarupplevelse i våra produkter, måste tjänsterna uppgraderas till tydligt frikopplade tjänster som alla produkter kan dra nytta av.

Små team är mer effektiva. Därför är det viktigt att sätta en maxstorlek på lag, så att de inte växer sig för stora och saktar ner.

Vi börjar implementera ett nytt koncept som vi kallar "pods" för att skapa mer struktur kring lämplig storlek på ett team. Inom varje produkt kommer vi att definiera poddar på <10 personer som arbetar med en specifik funktion eller område. Om en pod växer till att vara fler än 10 personer är det dags att dela upp den i två och tilldela var och en ett mer specifikt mål eller fokus. Pods måste också ha ett fokus och ett nordstjärnemått som knyter an till företagets övergripande statistik.

Inom växande företag finns det en risk att produkt- och ingenjörsteam börjar leverera fantastiska rutschbanor istället för fantastiska produkter. Det kan vara frestande att "klara sig" och känna att ett möte gick bra med en vacker kortlek som visades för överordnade. Men våra kunder ser aldrig rutschbanorna vi skapar. De ser bara produkten.

Så vi experimenterar med att förbjuda gliddäck i produkt- och tekniska recensioner. Istället för ett bildspel kan du visa:

• En instrumentpanel med dina mätvärden - förhoppningsvis tittar ditt team på detta åtminstone varje vecka ändå
• Figma mockups
• Men viktigast av allt...visa själva produkten och använd den live!

Det går bra att inkludera en ensidig agenda för att fånga åtgärder, eller för att länka till eventuella förläsningar som tekniska designdokument. Men den bästa användningen av tid i produkt- och tekniska recensioner är att dela din skärm och gå igenom den faktiska produkten på mobilen eller webben. Det kan vara produktionsversionen eller en iscensättningsversion. Det viktiga är att komma igång med produkten, se vad kunden ser (eller är på väg att se) och göra den bättre.

När vi gör detta bör vi undvika att lägga för mycket tid på att prata om vad som går bra på möten. Vi kan dela vad som går bra i förläsningen och ta en stund att fira det, men majoriteten av tiden på möten bör fokuseras på det som inte går bra, så att vi kan förbättra produkten.

Det är svårt att överskatta denna punkt. Inom företag finns det massor av saker som känns som arbete, men som i slutändan inte förbättrar kundupplevelsen — från marknadscykler och negativ press, till policyinsatser, internpolitik/drama, titlar och kompensation. Vi har team som fokuserar på dessa områden, så att den stora majoriteten av företaget (80%+) kan fortsätta fokusera på att prata med kunder och bygga bättre produkter.

Större företag bromsas också av ändlösa möten kring prioritering och funktionsförfrågningar. Vi måste gå över till en modell där alla produkt- och teknikteam (inte bara delade tjänster) publicerar API:er så att andra team kan dra nytta av det de bygger utan att någonsin behöva schemalägga ett möte. Med andra ord måste de produktisera sina tjänster och låta andra team använda dem på ett självbetjäningssätt.

Detta kräver att vi antar en intern API-katalog där alla ingenjörer på Coinbase kan bläddra för att hitta en lämplig tjänst. Utan detta är det svårt för alla ingenjörer att ens veta om ett API finns, vilket leder till dubbelarbete. Alla tjänster måste utformas med "asfalterade vägar", vilket innebär konsekventa bibliotek och språk för autentisering, loggning, instrumentering, etc. Många av dessa API:er kommer att dyka upp i Coinbase Cloud även för externa kunder, vilket gör dem ännu mer robusta.

I slutändan handlar mycket av detta om att behålla grundarmentaliteten inom företaget och agera som ägare. De flesta företag börjar med att vara anti-etablissemang och försöker rätta till något fel i världen. Men när de växer sig större och mer framgångsrika börjar de bli det nya etablissemanget. De blir självbelåtna, känner att de har vunnit, och byråkratin sätter in.

På Coinbase är en av våra värderingar repeterbar innovation, vilket innebär att vi alltid vill tänja på gränsen. Vi använder en 70/20/10 resursallokeringsmodell där vi investerar 70 % av våra resurser i vår kärnverksamhet och 20 % i strategiska ansträngningar, vi säkerställer också att 10 % av våra resurser alltid går till ambitiösa nya satsningar. Och vi försöker alltid göra produkter som är de mest pålitliga och enklaste att använda, så att vi kan få in en miljard människor till krypto. Detta är det bästa sättet att uppnå vårt uppdrag att öka den ekonomiska friheten i världen.

Coinbases framgång har alltid bottnat i en förmåga att arbeta effektivt med ett startup-tänk. Nu, när vi anpassar oss till vår nya skala, måste vi komma tillbaka till de saker som gjorde oss framgångsrika – att driva mer effektivitet och skaka av sig självbelåtenheten som kan smyga sig in i ett större företag. Vi måste ge våra ledare möjlighet att fatta beslut och våra team att leverera fantastiska produkter till kunder. Det kommer inte att bli lätt och vi måste fortsätta anpassa oss. Men vi har kommit så här långt, och jag är övertygad om att om vi fattar smarta beslut nu så kommer det bara att vara början.

Företag närmar sig problemet med sjunkande effektivitet på olika sätt, för att bäst passa deras situation. Vi har anpassat oss till att implementera dessa förändringar och verktyg efter att ha gjort betydande forskning om hur andra företag har navigerat i detta. Här är några fantastiska böcker och resurser som hjälpte mig att utbilda mig om detta ämne:

• Amp It Up: Frank Slootman har en stor blogginlägg om detta som blev till en bok. Kärnbudskapet är att när någon säger att jag återkommer till dig nästa vecka, säg vad sägs om imorgon. När någon säger att det kommer att ta sex månader, fråga hur vi skulle göra det om sex veckor eller sex dagar om vi var tvungna.
• Vänd skeppet: Kärnbudskapet i den här boken är istället för att fråga din chef vad du ska göra, berätta för honom eller henne vad du avser att göra, och de kommer att redigera ditt tänkande om det behövs. Du måste fortfarande informera, men det är ditt ansvar att bestämma den bästa vägen.
• Grundarnas mentalitet: Kärnbudskapet är att upprätthålla ett upproriskt tänkesätt, med en partiskhet för handling, djärvt uppdrag, kundförespråkande och mer. Prova quiz för mer detaljer.
• Koordination Motvind: Skalade organisationer måste vara löst kopplade och tätt anpassade. Med andra ord, anpassa sig till ett uppdrag, värderingar och mått på hög nivå, och ge ledare möjlighet att ta sin egen väg med mer lokaliserat beslutsfattande.