Virker effektivt i stor skala

Av Brian Armstrong, administrerende direktør og medgründer

Etter hvert som selskaper skalerer, bremser de vanligvis ned og blir mindre effektive. Det tar flere dollar, flere mennesker og mer tid å få noe gjort. Koordinasjonsmotvinden øker, vetokratier dukker opp, risikotoleransen forsvinner, og teamene blir fokusert innover i stedet for å holde fokus på kundene sine.

Selv om denne banen er naturlig, er den ikke uunngåelig. Alle store selskap, fra Amazon til Meta til Tesla, fant måter å beholde sin grunnleggende energi i forbindelse med passende kontroller, selv om de skalert til å være mye større enn Coinbase er i dag. Store selskaper opprettholder sin opprørske tankegang, i frykt for å bli selvtilfredse og irrelevante over tid.

Det er derfor vi fokuserer på å drive mer effektivitet hos Coinbase. Etter 18 måneder med ~200 % årlig vekst av ansatte, har mange av våre interne verktøy og organiseringsprinsipper begynt å slite eller gå i stykker. Så vi har gravd i for å identifisere settet med endringer vi må gjøre for å hjelpe oss med å lykkes i denne nye skalaen.

Det første trinnet var å redusere veksten vår betydelig og ta den vanskelige beslutningen om å redusere størrelsen på vårt nåværende team, noe vi kunngjorde forrige måned. Fremover vil vi fortsette å lete etter måter å gjøre Coinbase mer effektiv på, og for å komme tilbake til tankesettet og tilnærmingen som gjorde oss vellykkede. Jeg tror at disse trinnene vil bringe oss videre.

Vi bruker DRI-er (direkte ansvarlige personer) for å hjelpe oss med å utføre raskere. DRI-er balanserer innspill fra teamet og tar klare avgjørelser i tide.

Men nå som vi er et større selskap med mange produkter i stedet for ett, må vi justere hvordan vi tar beslutninger – presse de fleste beslutninger ned i organisasjonen, fjerne flaskehalser og styrke produktlederne våre.

DRI-er har ofte fristelsen til å presse beslutningsprosessen opp i kjeden når de ikke er sikre eller ikke vil ta risiko. Noen ganger er de redde for å få sparken hvis avgjørelsen ikke går bra. Det er derfor vi, der det er mulig, i økende grad fokuserer på å identifisere «en-trådede» DRIer. Single-threaded er teknisk sjargong som ganske enkelt betyr utelukkende fokusert på et enkelt område. Den enkeltgjengede DRI er den mest senior personen som har bare jobben er å drive et gitt produkt eller initiativ, dette vil typisk være en produktledelse eller ingeniørleder. De kan ikke være entråds DRI hvis de er DRI for flere områder.

Dette kan bety at ikke alle beslutninger er perfekte. Men det er OK hvis vi kan skalere innvirkningen vår og styrke fageksperter som er nærmere produktene og nærmere kundene våre.

Hvert av våre produkter har godt finansierte konkurrenter som er dedikerte selskaper. Vi tror den riktige måten å konkurrere på er å motivere våre produktledere til også å drive produktet deres mer som et frittstående selskap. Bedrifter må oppnå lønnsom vekst på en rimelig tidshorisont. Over tid vil vi være i stand til å gi produktledere direkte innsyn i deres P&L, slik at de kan flytte produktet mot positive marginer og ta bedre beslutninger rundt hvor de skal investere, mens vi på ledernivå vil fortsette å se på konsolidert ytelse.

Mens produktledere kan operere uavhengig, er det ofte felles elementer på tvers av produkter. Vi har delt tjenester rundt hvordan kunder ombord, administrerer kontoene deres, lagrer krypto, legger til betalingsmåter, handler krypto og mer. Gjøres det feil, kan delte tjenester bremse og frustrere produktteam. Men når de fungerer bra, kan de skape fantastiske synergier mellom produktene og dypere produktintegrasjon.

Produktteam bør ikke være pålagt å bruke en halvbakt delt tjeneste. Men når en delt tjeneste er moden, kan alle produkter være pålagt å bruke den. Vi har funnet ut at det ofte hjelper å starte en delt tjeneste med ett ankerprodukt i tankene. Når det blir klart at vi dupliserer innsats eller skaper en inkonsekvent brukeropplevelse på tvers av produktene våre, må tjenestene oppgraderes til klart frakoblede tjenester som ethvert produkt kan utnytte.

Små team er mer effektive. Derfor er det viktig å sette en maksimal størrelse på lag, så de ikke vokser seg for store og bremser ned.

Vi begynner å distribuere et nytt konsept som vi kaller "pods" for å skape mer struktur rundt passende størrelse på et team. Innenfor hvert produkt vil vi definere pods på <10 personer som jobber med en bestemt funksjon eller et bestemt område. Hvis en pod vokser til å være mer enn 10 personer, vil det være på tide å dele den i to og gi hver enkelt et mer spesifikt mål eller fokus. Pods må også ha et fokus, og en nordstjerne-beregning som knytter seg til de overordnede bedriftsberegningene.

Inne i selskaper i vekst er det en fare for at produkt- og ingeniørteam begynner å sende flotte lysbildebord i stedet for flotte produkter. Det kan være fristende å "klare seg" og føle at et møte gikk bra med en vakker kortstokk vist til overordnede. Men kundene våre ser aldri skyvedekkene vi lager. De ser bare produktet.

Så vi eksperimenterer med å forby skyvedekk i produkt- og tekniske anmeldelser. I stedet for en lysbildestokk kan du vise:

• Et dashbord med beregningene dine - forhåpentligvis ser teamet ditt på dette minst ukentlig uansett
• Figma-modeller
• Men viktigst av alt ... vis selve produktet og bruk det live!

Det er greit å inkludere en én-sides agenda for å fange handlingspunkter, eller å lenke til forhåndslesninger som tekniske designdokumenter. Men den beste bruken av tid i produkt- og tekniske vurderinger er å dele skjermen din og gå gjennom det faktiske produktet på mobil eller nett. Det kan være produksjonsversjonen, eller en iscenesettelsesversjon. Det viktige er å komme i gang med produktet, se hva kunden ser (eller er i ferd med å se), og gjøre det bedre.

Når vi gjør dette, bør vi unngå å bruke for mye tid på å snakke om hva som går bra i møter. Vi kan dele hva som går bra i forhåndslesingen, og bruke et øyeblikk på å feire det, men mesteparten av tiden i møter bør fokuseres på det som ikke går bra, slik at vi kan forbedre produktet.

Det er vanskelig å overdrive dette poenget. Inne i bedrifter er det mange ting som føles som jobb, men som til syvende og sist ikke forbedrer kundeopplevelsen – fra markedssykluser og negativ presse, til policyinnsats, intern politikk/drama, titler og kompensasjon. Vi har team som fokuserer på disse områdene, slik at det store flertallet av selskapet (80%+) kan forbli fokusert på å snakke med kunder og bygge bedre produkter.

Større selskaper blir også bremset av endeløse møter rundt prioritering og funksjonsforespørsler. Vi må gå over til en modell der alle produkt- og ingeniørteam (ikke bare delte tjenester) publiserer APIer slik at andre team kan dra nytte av det de bygger uten å måtte avtale et møte. Med andre ord, de må produktisere tjenestene sine og la andre team bruke dem på en selvbetjent måte.

Dette krever at vi tar i bruk en intern API-katalog der enhver ingeniør hos Coinbase kan bla gjennom for å finne en passende tjeneste. Uten dette er det vanskelig for enhver ingeniør å vite om det finnes et API, noe som fører til duplikatarbeid. Alle tjenester må bygges ved hjelp av "asfalterte veier", noe som betyr konsistente biblioteker og språk for autentisering, logging, instrumentering, etc. Mange av disse APIene vil også vises i Coinbase Cloud for eksterne kunder, noe som gjør dem enda mer robuste.

Til syvende og sist kommer mye av dette ned på å beholde grunnleggermentaliteten i selskapet og opptre som eiere. De fleste selskaper starter med å være anti-etablissementer, og prøver å rette opp noe galt i verden. Men etter hvert som de vokser seg større og mer suksessrike, begynner de å bli det nye etablissementet. De blir selvtilfredse, føler at de har vunnet, og byråkratiet setter inn.

Hos Coinbase er en av våre verdier repeterbar innovasjon, noe som betyr at vi alltid ønsker å presse grensen. Vi bruker en 70/20/10 ressursallokeringsmodell der vi investerer 70 % av ressursene våre i kjernevirksomheten vår, og 20 % i strategisk innsats. Vi sikrer også at 10 % av ressursene våre alltid går til ambisiøse nye spill. Og vi prøver alltid å lage produkter som er de mest pålitelige og enkleste å bruke, slik at vi kan bringe en milliard mennesker inn i krypto. Dette er den beste måten å oppnå vårt oppdrag om å øke økonomisk frihet i verden.

Coinbases suksess har alltid vært forankret i en evne til å operere effektivt med en oppstartstankegang. Nå, mens vi tilpasser oss den nye skalaen vår, må vi komme tilbake til tingene som gjorde oss vellykkede – å drive mer effektivitet og riste av seg selvtilfredsheten som kan snike seg inn i et større selskap. Vi må styrke lederne våre til å ta beslutninger, og teamene våre til å levere gode produkter til kundene. Det blir ikke lett, og vi må fortsette å justere. Men vi kom så langt, og jeg er sikker på at hvis vi tar smarte beslutninger nå, vil det bare være begynnelsen.

Bedrifter nærmer seg dette problemet med synkende effektivitet på forskjellige måter, for å passe deres situasjon best mulig. Vi har innrettet oss for å implementere disse endringene og verktøyene etter å ha gjort betydelige undersøkelser om hvordan andre selskaper har navigert i dette. Her er noen flotte bøker og ressurser som hjalp meg med å utdanne meg om dette emnet:

• Amp It Up: Frank Slootman har en flott blogginnlegg på dette som ble til en bok. Kjernebudskapet er at når noen sier at jeg skal komme tilbake til deg neste uke, si hva med i morgen. Når noen sier at det vil ta seks måneder, spør hvordan vi ville gjort det om seks uker eller seks dager hvis vi måtte.
• Snu skipet rundt: Kjernebudskapet i denne boken er i stedet for å spørre lederen din hva du bør gjøre, fortell ham eller henne hva du hensikt å gjøre, og de vil redigere tankegangen din om nødvendig. Du må fortsatt informere, men det er ditt ansvar å bestemme den beste veien.
• Grunnleggernes mentalitet: Kjernebudskapet er å opprettholde en opprørsk tankegang, med en skjevhet for handling, dristig oppdrag, kundestøtte og mer. Prøv quiz for mer informasjon.
• Koordinasjon motvind: Skalerte organisasjoner må være løst koblet og tett på linje. Med andre ord, innrett deg på et høyt nivå oppdrag, verdier og beregninger, og styrk deretter ledere til å ta sin egen vei med mer lokalisert beslutningstaking.