Operare in modo efficiente su larga scala

Di Brian Armstrong, CEO e co-fondatore

Man mano che le aziende crescono, di solito rallentano e diventano meno efficienti. Ci vogliono più dollari, più persone e più tempo per portare a termine qualsiasi cosa. Aumentano i venti contrari al coordinamento, emergono vetocrazie, la tolleranza al rischio svanisce e i team si concentrano su se stessi invece di rimanere concentrati sui propri clienti.

Sebbene questa traiettoria sia naturale, non è inevitabile. Ogni grande azienda, da Amazon a Meta a Tesla, ha trovato il modo di mantenere la propria energia fondatrice insieme a controlli adeguati, anche se si è ingrandita fino a diventare molto più grande di Coinbase oggi. Le grandi aziende mantengono la loro mentalità ribelle, per paura di diventare compiacenti e irrilevanti nel tempo.

Ecco perché ci stiamo concentrando sulla promozione di una maggiore efficienza in Coinbase. Dopo 18 mesi di crescita dei dipendenti di circa il 200% a/a, molti dei nostri strumenti interni e principi organizzativi hanno iniziato a cedere o a rompersi. Quindi abbiamo approfondito per identificare l'insieme di cambiamenti che dobbiamo apportare per aiutarci ad avere successo su questa nuova scala.

Il primo passo è stato rallentare in modo significativo la nostra crescita e prendere la difficile decisione di ridurre le dimensioni del nostro team attuale, che noi annunciato il mese scorso. Andando avanti, continueremo a cercare modi per rendere Coinbase più efficiente e per tornare alla mentalità e all'approccio che ci hanno permesso di avere successo. Credo che questi passi ci porteranno avanti.

Utilizziamo i DRI (individui direttamente responsabili) per aiutarci a eseguire più rapidamente. I DRI bilanciano gli input del team e prendono decisioni chiare in modo tempestivo.

Ma ora che siamo un'azienda più grande con molti prodotti invece di uno solo, dobbiamo adattare il modo in cui prendiamo le decisioni, spingendo la maggior parte del processo decisionale all'interno dell'organizzazione, rimuovendo i colli di bottiglia e dando maggiore potere ai nostri leader di prodotto.

I DRI hanno spesso la tentazione di spingere il processo decisionale lungo la catena quando non sono sicuri o non vogliono correre rischi. A volte hanno paura di essere licenziati se la decisione non va bene. Ecco perché, ove possibile, siamo sempre più concentrati sull'identificazione di DRI “a thread singolo”. Single-thread è il gergo tecnologico che significa semplicemente focalizzato esclusivamente su una singola area. Il DRI a thread singolo è la persona più anziana di cui esclusivamente Il lavoro è gestire un determinato prodotto o iniziativa, in genere si tratterà di un leader nella gestione del prodotto o nell'ingegneria. Non possono essere DRI a thread singolo se sono DRI di più aree.

Ciò può significare che non tutte le decisioni sono perfette. Ma va bene se riusciamo ad aumentare il nostro impatto e a dare potere agli esperti in materia che sono più vicini ai prodotti e più vicini ai nostri clienti.

Ciascuno dei nostri prodotti ha concorrenti ben finanziati che sono aziende dedicate. Riteniamo che il modo giusto per competere sia incentivare i nostri leader di prodotto a gestire i loro prodotti in modo più simile a un'azienda autonoma. Le aziende devono raggiungere una crescita redditizia in un orizzonte temporale ragionevole. Nel corso del tempo, saremo in grado di offrire ai leader di prodotto una visibilità diretta sui loro profitti e perdite, in modo che possano spostare il loro prodotto verso margini positivi e prendere decisioni migliori su dove investire, mentre a livello esecutivo continueremo a guardare alle prestazioni consolidate.

Sebbene i leader di prodotto possano operare in modo indipendente, spesso esistono elementi comuni tra i prodotti. Abbiamo condiviso servizi su come i clienti effettuano l'onboarding, gestiscono i propri account, archiviano criptovalute, aggiungono metodi di pagamento, scambiano criptovalute e altro ancora. Se eseguiti in modo errato, i servizi condivisi possono rallentare e frustrare i team di prodotto. Ma quando funzionano bene, possono creare straordinarie sinergie tra i prodotti e una più profonda integrazione dei prodotti.

Ai team di prodotto non dovrebbe essere richiesto di utilizzare un servizio condiviso a metà. Ma una volta che un servizio condiviso è maturo, a tutti i prodotti potrebbe essere richiesto di utilizzarlo. Abbiamo scoperto che spesso è utile avviare un servizio condiviso con in mente un prodotto di ancoraggio. Quando diventa chiaro che stiamo duplicando gli sforzi o creando un’esperienza utente incoerente tra i nostri prodotti, i servizi devono passare a servizi chiaramente disaccoppiati che qualsiasi prodotto può sfruttare.

I piccoli team sono più efficienti. Ecco perché è importante impostare una dimensione massima per i team, in modo che non diventino troppo grandi e rallentino.

Stiamo iniziando a implementare un nuovo concetto che chiamiamo "pod" per creare una maggiore struttura attorno alla dimensione appropriata di un team. All'interno di ciascun prodotto, definiremo pod di meno di 10 persone che lavoreranno su una funzione o un'area specifica. Se un pod cresce fino a contenere più di 10 persone, sarà il momento di dividerlo in due e assegnare a ciascuno un obiettivo o focus più specifico. Anche i pod devono avere un focus e una metrica della stella polare che si colleghi alle metriche aziendali generali.

All'interno delle aziende in crescita, c'è il pericolo che i team di prodotto e di ingegneria inizino a spedire grandi mazzi di diapositive invece di ottimi prodotti. Può essere forte la tentazione di "arrangiarsi" e sentirsi come se una riunione fosse andata alla grande con un bellissimo mazzo mostrato ai superiori. Ma i nostri clienti non vedono mai le diapositive che creiamo. Vedono solo il prodotto.

Quindi stiamo sperimentando il divieto delle presentazioni nelle revisioni di prodotto e di progettazione. Invece di una presentazione, puoi mostrare:

• Una dashboard con le tue metriche: si spera che il tuo team la guardi comunque almeno settimanalmente
• Mockup Figma
• Ma soprattutto...mostra il prodotto stesso e usalo dal vivo!

Va bene includere un'agenda di una pagina per acquisire elementi di azione o collegarsi a eventuali letture preliminari come documenti di progettazione tecnica. Ma il miglior utilizzo del tempo nelle revisioni di prodotti e di progettazione è condividere lo schermo ed esaminare il prodotto reale su dispositivo mobile o Web. Potrebbe essere la versione di produzione o una versione di staging. L'importante è toccare con mano il prodotto, vedere cosa vede il cliente (o sta per vedere) e migliorarlo.

Mentre lo facciamo, dovremmo evitare di spendere troppo tempo a parlare di ciò che sta andando bene durante le riunioni. Possiamo condividere ciò che sta andando bene nella pre-lettura e prenderci un momento per celebrarlo, ma la maggior parte del tempo nelle riunioni dovrebbe essere concentrato su ciò che non sta andando bene, in modo da poter migliorare il prodotto.

È difficile sopravvalutare questo punto. All'interno delle aziende, ci sono molte cose che sembrano lavoro, ma che alla fine non migliorano l'esperienza del cliente: dai cicli di mercato e dalla stampa negativa, agli sforzi politici, alla politica/drammi interni, ai titoli e ai compensi. Disponiamo di team che si concentrano su queste aree, in modo che la stragrande maggioranza dell'azienda (oltre l'80%) possa rimanere concentrata sul dialogo con i clienti e sulla creazione di prodotti migliori.

Anche le aziende più grandi vengono rallentate da riunioni infinite sulla definizione delle priorità e sulle richieste di funzionalità. Dobbiamo passare a un modello in cui tutti i team di prodotto e di ingegneria (non solo i servizi condivisi) pubblicano le API in modo che altri team possano trarre vantaggio da ciò che stanno costruendo senza mai dover programmare una riunione. In altre parole, devono produrre i propri servizi e consentire ad altri team di utilizzarli in modalità self-service.

Ciò richiede l'adozione di un catalogo API interno in cui qualsiasi ingegnere di Coinbase possa navigare per trovare un servizio appropriato. Senza questo, è difficile per qualsiasi ingegnere sapere se esiste un'API, il che porta a duplicare il lavoro. Tutti i servizi devono essere progettati utilizzando "strade asfaltate", ovvero librerie e linguaggi coerenti per l'autenticazione, la registrazione, la strumentazione, ecc. Molte di queste API verranno rese disponibili in Coinbase Cloud anche per i clienti esterni, rendendole ancora più robuste.

In definitiva, molto di ciò si riduce al mantenimento della mentalità del fondatore all’interno dell’azienda e all’agire come proprietari. La maggior parte delle aziende iniziano con l’essere anti-establishment, cercando di correggere alcuni errori nel mondo. Ma man mano che diventano più grandi e hanno più successo, iniziano a diventare la nuova struttura. Si accontentano, sentendo di aver vintoe subentra la burocrazia.

In Coinbase, uno dei nostri valori è l'innovazione ripetibile, il che significa che vogliamo sempre spingerci oltre i confini. Utilizziamo un modello di allocazione delle risorse 70/20/10 in cui investiamo il 70% delle nostre risorse nel nostro core business e il 20% in sforzi strategici, garantendo inoltre che il 10% delle nostre risorse sia sempre destinato a nuove ambiziose scommesse. E cerchiamo sempre di realizzare prodotti che siano i più affidabili e facili da usare, in modo da poter coinvolgere un miliardo di persone nel mondo delle criptovalute. Questo è il modo migliore per realizzare la nostra missione di aumentare la libertà economica nel mondo.

Il successo di Coinbase è sempre stato radicato nella capacità di operare in modo efficiente con una mentalità da startup. Ora, mentre ci adattiamo alla nostra nuova dimensione, dobbiamo tornare alle cose che ci hanno permesso di avere successo: aumentare l’efficienza e scrollarci di dosso l’autocompiacimento che può insinuarsi in un’azienda più grande. Dobbiamo consentire ai nostri leader di prendere decisioni e ai nostri team di fornire ottimi prodotti ai clienti. Non sarà facile e dovremo continuare ad adattarci. Ma siamo arrivati ​​fin qui e sono fiducioso che, se prendiamo decisioni intelligenti adesso, sarà solo l’inizio.

Le aziende affrontano questo problema di calo di efficienza in modi diversi, per adattarsi al meglio alla loro situazione. Ci siamo allineati sull'implementazione di questi cambiamenti e strumenti dopo aver svolto ricerche approfondite su come altre aziende hanno affrontato questo problema. Ecco alcuni ottimi libri e risorse che mi hanno aiutato a istruirmi su questo argomento:

• Amplificalo: Frank Slootman ha un grande post sul blog su questo che è diventato un libro. Il messaggio principale è che quando qualcuno dice che ti ricontatterò la prossima settimana, digli che ne dici di domani. Quando qualcuno dice che ci vorranno sei mesi, chiedi come lo faremmo in sei settimane o sei giorni se dovessimo farlo.
• Girare la nave: Il messaggio centrale di questo libro è invece di chiedere al tuo manager cosa dovresti fare, digli cosa vuoi fare intendono da fare e, se necessario, modificheranno il tuo pensiero. Devi comunque informarti, ma è tua responsabilità decidere la strada migliore.
• Mentalità dei fondatori: Il messaggio principale è mantenere una mentalità ribelle, con una propensione all'azione, una missione coraggiosa, la difesa dei clienti e altro ancora. Prova il quiz per ulteriori dettagli.
• Coordinazione Venti contrari: Le organizzazioni su larga scala devono essere poco accoppiate e strettamente allineate. In altre parole, allinearsi su una missione, valori e parametri di alto livello, quindi consentire ai leader di creare il proprio percorso con un processo decisionale più localizzato.