Efficiënt werken op schaal

Door Brian Armstrong, CEO en medeoprichter

Naarmate bedrijven schalen, vertragen ze meestal en worden ze minder efficiënt. Het kost meer dollars, meer mensen en meer tijd om iets gedaan te krijgen. Coördinatie tegenwind neemt toe, vetocratieën ontstaan, risicotolerantie neemt af en teams worden innerlijk gefocust in plaats van gefocust te blijven op hun klanten.

Hoewel dit traject natuurlijk is, is het niet onvermijdelijk. Elk groot bedrijf, van Amazon tot Meta tot Tesla, vond manieren om hun oprichtingsenergie te behouden in combinatie met de juiste controles, zelfs toen ze opschaalden om veel groter te zijn dan Coinbase vandaag is. Grote bedrijven behouden hun opstandige mentaliteit, uit angst om na verloop van tijd zelfgenoegzaam en irrelevant te worden.

Daarom richten we ons bij Coinbase op het stimuleren van meer efficiëntie. Na 18 maanden van ~200% y/y werknemersgroei, beginnen veel van onze interne tools en organisatieprincipes te belasten of te breken. We hebben ons dus verdiept in het identificeren van de reeks veranderingen die we moeten doorvoeren om ons te helpen slagen op deze nieuwe schaal.

De eerste stap was het aanzienlijk vertragen van onze groei en het nemen van de moeilijke beslissing om de omvang van ons huidige team te verkleinen, wat we vorige maand aangekondigd. In de toekomst blijven we zoeken naar manieren om Coinbase efficiënter te maken en terug te keren naar de mindset en aanpak die ons succesvol hebben gemaakt. Ik geloof dat deze stappen ons vooruit zullen helpen.

We gebruiken DRI's (direct verantwoordelijke individuen) om ons te helpen sneller uit te voeren. DRI's balanceren de input van het team en nemen tijdig duidelijke beslissingen.

Maar nu we een groter bedrijf zijn met veel producten in plaats van één, moeten we de manier waarop we beslissingen nemen aanpassen — de meeste besluitvorming in de organisatie naar beneden duwen, knelpunten wegnemen en onze productleiders machtigen.

DRI's hebben vaak de verleiding om de besluitvorming in de keten te duwen als ze niet zeker zijn of geen risico willen nemen. Soms zijn ze bang om ontslagen te worden als de beslissing niet goed gaat. Daarom richten we ons, waar mogelijk, steeds meer op het identificeren van 'single-threaded' DRI's. Single-threaded is technisch jargon dat simpelweg betekent dat u zich uitsluitend op één gebied concentreert. De single-threaded DRI is de oudste persoon wiens Slechts taak is om een ​​bepaald product of initiatief te runnen, dit is meestal een leider op het gebied van productbeheer of engineering. Ze kunnen niet de single-threaded DRI zijn als ze de DRI van meerdere gebieden zijn.

Dit kan betekenen dat niet elke beslissing perfect is. Maar dat is oké als we onze impact kunnen schalen en materiedeskundigen in staat stellen die dichter bij de producten en dichter bij onze klanten staan.

Elk van onze producten heeft goed gefinancierde concurrenten die toegewijde bedrijven zijn. Wij geloven dat de juiste manier om te concurreren is om onze productleiders te stimuleren om hun product ook meer als een op zichzelf staand bedrijf te runnen. Bedrijven moeten binnen een redelijke tijdshorizon winstgevende groei realiseren. Na verloop van tijd zullen we productleiders direct inzicht kunnen geven in hun P&L, zodat ze hun product naar positieve marges kunnen sturen en betere beslissingen kunnen nemen over waar te investeren, terwijl we op directieniveau zullen blijven kijken naar geconsolideerde prestaties.

Hoewel productleiders onafhankelijk kunnen opereren, zijn er vaak gemeenschappelijke elementen in producten. We hebben gedeelde services over hoe klanten aan boord komen, hun accounts beheren, crypto opslaan, betaalmethoden toevoegen, crypto verhandelen en meer. Verkeerd gedaan, gedeelde services kunnen productteams vertragen en frustreren. Maar als ze goed werken, kunnen ze verbazingwekkende synergieën tussen producten en diepere productintegratie creëren.

Productteams zouden niet verplicht moeten worden om een ​​halfbakken gedeelde service te gebruiken. Maar zodra een gedeelde service volwassen is, is het mogelijk dat alle producten deze moeten gebruiken. We hebben gemerkt dat het vaak helpt om een ​​gedeelde service te starten met één ankerproduct in gedachten. Wanneer duidelijk wordt dat we onze inspanningen verdubbelen of een inconsistente gebruikerservaring creëren voor onze producten, moeten services overgaan in duidelijk ontkoppelde services die elk product kan benutten.

Kleine teams zijn efficiënter. Daarom is het belangrijk om een ​​maximale grootte op teams in te stellen, zodat ze niet te groot worden en vertragen.

We beginnen een nieuw concept te implementeren dat we 'pods' noemen om meer structuur te creëren rond de juiste grootte van een team. Binnen elk product zullen we pods definiëren van <10 mensen die aan een specifiek kenmerk of gebied werken. Als een pod uitgroeit tot meer dan 10 personen, wordt het tijd om deze in tweeën te splitsen en elk een specifieker doel of focus toe te wijzen. Pods moeten ook een focus hebben en een noordsterstatistiek die aansluit bij de algemene bedrijfsstatistieken.

Binnen groeiende bedrijven bestaat het gevaar dat product- en engineeringteams geweldige slides-decks gaan verzenden in plaats van geweldige producten. Het kan verleidelijk zijn om het te "managen" en het gevoel te hebben dat een vergadering geweldig is verlopen met een prachtig kaartspel dat aan superieuren wordt getoond. Maar onze klanten zien nooit de dia's die we maken. Ze zien alleen het product.

Dus we experimenteren met het verbieden van diapresentaties in product- en technische recensies. In plaats van een diapresentatie kunt u het volgende laten zien:

• Een dashboard met uw statistieken - hopelijk bekijkt uw team dit sowieso minstens wekelijks
• Figma-mockups
• Maar het allerbelangrijkste….toon het product zelf en gebruik het live!

Het is prima om een ​​agenda van één pagina op te nemen om actie-items vast te leggen, of om te linken naar pre-reads zoals technische ontwerpdocumenten. Maar het beste gebruik van tijd in product- en technische beoordelingen is om uw scherm te delen en door het eigenlijke product te lopen op mobiel of internet. Het kan de productieversie zijn, of een staging-versie. Het belangrijkste is om hands-on met het product aan de slag te gaan, te zien wat de klant ziet (of gaat zien) en het beter te maken.

Terwijl we dit doen, moeten we voorkomen dat we te veel tijd besteden aan praten over wat er goed gaat in vergaderingen. We kunnen delen wat er goed gaat in de pre-read, en een moment nemen om het te vieren, maar het grootste deel van de tijd in vergaderingen moet gericht zijn op wat niet goed gaat, zodat we het product kunnen verbeteren.

Het is moeilijk om dit punt te overschatten. Binnen bedrijven zijn er tal van dingen die aanvoelen als werk, maar uiteindelijk de klantervaring niet verbeteren - van marktcycli en negatieve pers tot beleidsinspanningen, interne politiek/drama, titels en vergoedingen. We hebben teams die zich op deze gebieden concentreren, zodat de overgrote meerderheid van het bedrijf (80%+) gefocust kan blijven op het praten met klanten en het bouwen van betere producten.

Grotere bedrijven worden ook afgeremd door eindeloze vergaderingen over prioritering en functieverzoeken. We moeten overstappen naar een model waarin alle product- en engineeringteams (niet alleen gedeelde services) API's publiceren, zodat andere teams kunnen profiteren van wat ze bouwen zonder ooit een vergadering te hoeven plannen. Met andere woorden, ze moeten hun diensten in productie nemen en andere teams toestaan ​​deze op een zelfbedieningsmanier te gebruiken.

Dit vereist dat we een interne API-catalogus gebruiken waar elke ingenieur bij Coinbase kan bladeren om een ​​geschikte service te vinden. Zonder dit is het voor elke ingenieur moeilijk om zelfs maar te weten of een API bestaat, wat leidt tot dubbel werk. Alle services moeten worden ontworpen met behulp van "verharde wegen", wat betekent consistente bibliotheken en talen voor authenticatie, logging, instrumentatie, enz. Veel van deze API's zullen ook voor externe klanten in Coinbase Cloud worden opgedoken, waardoor ze nog robuuster worden.

Uiteindelijk komt veel hiervan neer op het behouden van de oprichtersmentaliteit binnen het bedrijf en het optreden als eigenaren. De meeste bedrijven beginnen met anti-establishment en proberen een fout in de wereld recht te zetten. Maar naarmate ze groter en succesvoller worden, beginnen ze de nieuwe vestiging te worden. Ze worden zelfgenoegzaam, het gevoel hebben dat ze hebben gewonnenen bureaucratie treedt in.

Bij Coinbase is een van onze waarden herhaalbare innovatie, wat betekent dat we altijd de grens willen verleggen. We gebruiken een 70/20/10 toewijzingsmodel voor middelen waarbij we 70% van onze middelen investeren in onze kernactiviteiten en 20% in strategische inspanningen. We zorgen er ook voor dat 10% van onze middelen altijd naar ambitieuze nieuwe weddenschappen gaan. En we proberen altijd producten te maken die het meest vertrouwd en gemakkelijkst te gebruiken zijn, zodat we een miljard mensen in crypto kunnen brengen. Dit is de beste manier om onze missie om de economische vrijheid in de wereld te vergroten, te verwezenlijken.

Het succes van Coinbase is altijd geworteld in het vermogen om efficiënt te werken met een startup-mentaliteit. Nu we ons aanpassen aan onze nieuwe schaal, moeten we teruggaan naar de dingen die ons succesvol hebben gemaakt - om meer efficiëntie te stimuleren en de zelfgenoegzaamheid van ons af te schudden die een groter bedrijf kan binnensluipen. We moeten onze leiders in staat stellen om beslissingen te nemen, en onze teams om geweldige producten aan klanten te leveren. Het zal niet gemakkelijk zijn en we zullen ons moeten blijven aanpassen. Maar we zijn zo ver gekomen en ik ben ervan overtuigd dat als we nu slimme beslissingen nemen, dit slechts het begin zal zijn.

Bedrijven benaderen dit probleem van afnemende efficiëntie op verschillende manieren, passend bij hun situatie. We hebben overeenstemming bereikt over het implementeren van deze wijzigingen en tools na uitgebreid onderzoek te hebben gedaan naar hoe andere bedrijven dit hebben aangepakt. Hier zijn een paar geweldige boeken en bronnen die me hebben geholpen over dit onderwerp:

• Versterk het: Frank Slootman heeft een geweldige blogpost hierover is een boek geworden. De kernboodschap is dat als iemand zegt dat ik volgende week bij je terugkom, zeg wat van morgen. Als iemand zegt dat het zes maanden zal duren, vraag dan hoe we het in zes weken of zes dagen zouden doen als het moest.
• Draai het schip om: De kernboodschap van dit boek is, in plaats van je manager te vragen wat je moet doen, hem of haar vertellen wat je doet voornemens zijn te doen, en ze zullen je denken aanpassen als dat nodig is. U moet nog steeds informeren, maar het is uw verantwoordelijkheid om de beste weg te bepalen.
• Oprichtersmentaliteit: De kernboodschap is om een ​​opstandige mentaliteit te behouden, met een voorliefde voor actie, gedurfde missie, belangenbehartiging van klanten en meer. Probeer de quiz voor meer details.
• Coördinatie Tegenwind: Geschaalde organisaties moeten losjes gekoppeld en strak op elkaar zijn afgestemd. Met andere woorden, stem af op een missie, waarden en meetwaarden op hoog niveau, en stel leiders vervolgens in staat hun eigen weg te gaan met meer gelokaliseerde besluitvorming.