Alimentare l'innovazione e la velocità con i team da due pizze di Amazon

Amazon, come molte aziende nate durante l'era delle dot-com, è stata organizzata per essere agile e veloce e offrire valore costante ai clienti. Nella sua primissima lettera agli azionisti del 1997, Jeff Bezos ha parlato dell'importanza di concentrarsi incessantemente sui clienti e di generare valore continuo a lungo termine per loro conto, anche a scapito degli utili aziendali a breve termine. Questa incessante attenzione per il cliente si basava sulla realizzazione e il mantenimento di una struttura organizzativa composta da sviluppatori propositivi, competenti, entusiasti di svegliarsi ogni giorno per risolvere i problemi più spinosi dei clienti e inventare per loro conto.

"Stabilire un livello elevato nel nostro approccio alle assunzioni", ha scritto Jeff, "è stato e continuerà ad essere l'elemento più importante del successo di Amazon.com."

Ciò era più facile da realizzare agli inizi, quando l'azienda era focalizzata sull'e-commerce e i team – così come l'architettura tecnica a cui si affidavano per innovare velocemente – erano più centralizzati e strettamente collegati. Tuttavia, con il passare del tempo, man mano che Amazon espandeva le sue attività e introduceva innovazioni per soddisfare le esigenze dei clienti, la velocità e l'agilità con cui riusciva ad operare erano messe a dura prova. Il desiderio di rimanere una “macchina delle invenzioni”, come ha sottolineato Jeff nella sua lettera agli azionisti del 2015, ovvero una società in grado di “combinare le straordinarie capacità di servire i clienti rese possibili dalle dimensioni con la velocità di movimento, l'agilità e la mentalità di accettazione del rischio normalmente associate alle start-up imprenditoriali”, ha iniziato a risentirne. La nostra architettura e la nostra organizzazione strettamente collegate semplicemente non ci aiutavano a muoverci con la velocità desiderata o necessaria.

Per far fronte alla crescente lentezza e inefficienza, abbiamo cambiato radicalmente la nostra architettura tecnica con quella che è conosciuta come architettura di microservizi. Abbiamo diviso la nostra architettura monolitica in una vasta rete di servizi singoli e autonomi. In questo modo siamo stati in grado di lanciare rapidamente nuove innovazioni e offerte, iterare velocemente i servizi esistenti in base alle sempre mutevoli necessità dei clienti e sperimentare costantemente nuove idee per inventare per conto loro.

Ma non bastava semplicemente revisionare la tecnologia utilizzata dai nostri sviluppatori per promuovere l'innovazione. Avevamo bisogno anche di ristrutturare l'organizzazione dei team per massimizzarne la capacità di stare vicino ai clienti e alle loro esigenze, lanciare rapidamente prodotti e servizi innovativi per loro conto e sfruttare al meglio l'agilità e la velocità offerte da un'architettura cloud di microservizi. Questa struttura organizzativa divenne nota come "team da due pizze" di Amazon.

Il concetto dei team da due pizze di Amazon è semplice: nessuna squadra dovrebbe essere abbastanza grande da richiedere più di due pizze per sfamarsi. Mettendo da parte il numero o la natura dei condimenti (non abbiamo tempo e spazio per risolvere il dibattito: "l'ananas può andare sulla pizza?"), idealmente, si tratta di un team di meno di 10 persone: i team più piccoli riducono al minimo le linee di comunicazione e riducono il carico burocratico e decisionale. Ciò consente ai team da due pizze di dedicare più tempo ai propri clienti e a sperimentare e innovare costantemente per loro conto: la massima priorità dei team ad alte prestazioni di Amazon.

inoltre, nei team più piccoli i singoli individui sono più responsabilizzati e hanno più libertà di iniziativa. Ciò può ridurre l'effetto Ringelmann: una tendenza alla diminuzione della produttività individuale in gruppi più numerosi. Con l'aumentare delle risorse del team, ci si concentra meno sullo sforzo individuale, poiché le persone si affidano maggiormente agli altri per sostenere il carico. L'entità del contributo individuale diminuisce con l'aumentare delle dimensioni del team. Al contrario, lo sforzo individuale aumenta al diminuire delle dimensioni del team.

I team più piccoli aumentano anche la soddisfazione dei dipendenti, una preoccupazione fondamentale poiché le organizzazioni odierne si sforzano di attrarre e mantenere i migliori talenti. Un noto studio di Hackman e Vidmar mostra che la soddisfazione individuale diminuisce con l'aumentare delle dimensioni del team. Spesso, nei team di grandi dimensioni, i contributi individuali sono meno riconoscibili e la responsabilità individuale su aspetti specifici diventa più distribuita.

Questo aspetto è stato confermato da studi sulla forza lavoro; lo studio “The State of the American Workplace” (Lo stato degli ambienti di lavoro negli Stati Uniti) di Gallup ha mostrato che le organizzazioni con meno di 10 dipendenti hanno ottenuto livelli di coinvolgimento del 42% o superiori, mentre il livello medio per le organizzazioni più grandi era inferiore al 30%.

Ma il concetto di team da due pizze di Amazon non è solo questione di dimensioni. Un fattore chiave per consentire l'innovazione e la velocità costanti in una struttura del team da due pizze è offrire loro la possibilità di concentrarsi su un singolo progetto.

► Ascolta il podcast: C-Suite Strategies for Leading Significant Change

In sostanza, un team da due pizze non è solo questione di dimensioni, ma mira anche a responsabilizzare e rendere indipendenti i team.

In Amazon e AWS, i team da due pizze hanno la piena responsabilità di un prodotto o un servizio specifico. Invece di mantenere sistemi complessi o risolvere problemi che riguardano più servizi, linee di business o segmenti di clienti, i team da due pizze si concentrano su un solo servizio o offerta e solo sui clienti che li utilizzano. Questo approccio promuove l'efficienza e la scalabilità. Il programma dei team da due pizze, inclusi i compromessi e le priorità che devono raggiungere, si concentra esclusivamente sull'innovazione del loro servizio e del segmento di clienti che lo utilizza.

La struttura a due pizze promuove anche la responsabilità del team. I team da due pizze non affidano a un'altra squadra la gestione di qualcosa che hanno lanciato loro. Questa responsabilità specifica si estende all'intera esperienza del cliente e all'intero ciclo di vita del prodotto o servizio di un team da due pizze.

Pertanto, i team da due pizze devono rimanere al passo con ogni aspetto del proprio servizio, con una rotta chiara e una missione ben definita. Devono rimanere vicini ai propri clienti e creare i meccanismi di monitoraggio, le metriche e i KPI corretti per garantire che il loro servizio offra costantemente valore ai clienti.

Ciò richiede anche che un team da due pizze disponga delle risorse corrette (ingegneria, test, gestione di prodotti e programmi, operazioni ecc.) per gestire e controllare più facilmente il proprio servizio dall'inizio alla fine.

Con l'aumento delle richieste di un prodotto o servizio, anziché aggiungere molti altri membri al team, cerchiamo modi per suddividere i team in gruppi di team da due pizze che lavorano su una sottoarea del servizio, a sua volta organizzata come progetto individuale. Questa mitosi mantiene una struttura organizzativa più piatta che preserva l'agilità, l'autonomia e la responsabilità assoluta e specifica sul progetto.

In sostanza, un team da due pizze non è solo questione di dimensioni; mira anche a responsabilizzare e rendere indipendenti i team sotto ogni aspetto, dall'ideazione all'esecuzione, dal miglioramento operativo continuo alla costante iterazione e innovazione del prodotto. Consente ai team di operare velocemente, sperimentare con tempestività e frequenza e applicare rapidamente le conoscenze acquisite per offrire costantemente valore ai propri clienti. L'innovazione e la sperimentazione più rapide aiutano anche a ridurre i costi del fallimento: le lezioni si apprendono più rapidamente e con una posta in gioco inferiore rispetto a quella richiesta nelle fasi successive dello sviluppo.

Sebbene la struttura dei team da due pizze abbia funzionato per Amazon e AWS, siamo consapevoli che potrebbe non essere adatta a tutte le organizzazioni o a tutte le unità aziendali. I team da due pizze non sono perfetti e non sono immuni a limitazioni; ad esempio, con così tanti team autonomi che operano velocemente per soddisfare le esigenze dei propri clienti, c'è il rischio di duplicazioni e di uno sviluppo a compartimenti stagni. Hai bisogno della giusta struttura di governance per decidere quando e come combinare sforzi puramente replicativi, senza soffocare la capacità dei team di promuovere l'innovazione nelle rispettive aree di competenza.

A causa della rapida sperimentazione, è inoltre necessaria la collaborazione tra team per moltiplicare il successo e razionalizzare le risorse. Ancora più importante è la capacità di cogliere e condividere gli insegnamenti tratti dai fallimenti per applicare meglio tali lezioni agli esperimenti successivi, e per ottimizzare la direzione dell'iterazione e delle decisioni di investimento future.

Un aspetto dell'organizzazione di Amazon e AWS che aiuta a promuovere la governance e la supervisione, consentendo al contempo ai team di lavorare in modo rapido, indipendente e autonomo, è il concetto di leader dedicato, o Single-Threaded Leader.

Il ruolo dei leader dedicati è fondamentale per istituire il livello di supervisione corretto per mantenere la capacità di un team di innovare in modo indipendente per conto dei propri clienti.

I dirigenti di oggi comprendono l'enorme vantaggio di poter offrire rapidamente innovazione e trasformazione digitale. La capacità di immettersi rapidamente sul mercato con nuovi prodotti e servizi non è solo fondamentale per fornire valore costante ai clienti, ma può anche diventare un vantaggio competitivo differenziante per l'azienda. Tuttavia, con l'aumentare della dimensione e della portata dell'attività, i dirigenti devono assicurarsi di creare la struttura e la leadership corrette per garantire ai team la capacità di operare velocemente.

La governance e la gestione dei team devono fornire "guardrail", meccanismi che consentono ai team di agire velocemente e prendere decisioni ponderate ad alta velocità, anziché "caselli" che ostacolano la velocità creando lunghe code per l'approvazione o il coordinamento prima di consentire ai team di progredire con esperimenti innovativi.

In Amazon e AWS, il ruolo dei leader dedicati è fondamentale per istituire il giusto livello di supervisione per mantenere la capacità di un team di innovare in modo indipendente per conto dei propri clienti, creando al contempo meccanismi coerenti che consentano il livello di ispezione e visione direzionale corretti. I leader dedicati aiutano a fornire una visione strategica, ma non ostacolano il proprio team. I leader dei team devono aiutare a rimuovere gli ostacoli invece di costituire una barriera attraverso la quale devono passare tutte le decisioni. I team piccoli, agili e autonomi, costantemente concentrati sui propri clienti, sono i principali esperti per quanto riguarda i propri servizi e segmenti di clientela.

I leader dedicati devono preservare l'autonomia del proprio team per prendere le decisioni migliori per l'azienda. Il coinvolgimento dei leader dedicati nel processo decisionale del proprio team serve spesso a guidare il team in situazioni in cui, anche con la giusta strumentazione di dati e il massimo giudizio, il percorso da seguire potrebbe non essere chiaro.

Un meccanismo utilizzato da Amazon per facilitare la supervisione di un leader dedicati su questi checkpoint sono le narrazioni scritte. Le narrazioni in queste circostanze aiutano a delineare il problema che è emerso con il cliente; raccolgono informazioni da analisi approfondite e dati ottenuti dal team per definire le fasi successive; espongono la decisione consigliata dal team, insieme ai percorsi alternativi presi in considerazione e ai rischi e ai benefici di ciascuno di questi percorsi.

Sebbene dedicare del tempo alla stesura di una narrazione possa sembrare in conflitto con un'esecuzione veloce e costante, l'uso di narrazioni in Amazon e AWS ha portato vantaggi straordinari. Il primo vantaggio è che questi documenti sono spesso molto discussi e perfezionati dal team, dai suoi stakeholder e dagli esperti in materia dell'offerta e del segmento di clienti del team ancor prima che arrivino sulla scrivania di un dirigente. Ciò favorisce la collaborazione e la varietà di prospettive, mette in dubbio le supposizioni e serve a perfezionare le idee e i suggerimenti all'interno del documento. In definitiva, la narrazione porta spesso a decisioni di qualità superiore.

Ci sono molte narrazioni diverse in Amazon e AWS. Alcune sono incentrate sul lancio di nuovi prodotti, come il nostro documento PR/FAQ (che sta per Comunicato stampa/Domande frequenti), che è il prodotto del nostro approccio Lavorare in retrospettiva. Altre sono revisioni aziendali operative (spesso con cadenza settimanale, mensile e trimestrale) che forniscono ispezione e governance sulle metriche, le tendenze, le tensioni, i rischi e le opportunità chiave che si presentano nell'attività di un team.

Disponiamo di narrazioni che forniscono rigorose revisioni della conformità operativa prima del lancio di qualsiasi nuovo servizio, le quali offrono approfondimenti per garantire che gli aspetti dell'architettura di un servizio, la qualità e le procedure di rilascio e le relative procedure di gestione degli incidenti e degli eventi siano ben formulati e documentati. Altre narrazioni, come il nostro documento sulla correzione degli errori, vengono elaborate post mortem quando un servizio ha un impatto negativo sui clienti. Questi documenti sono redatti dal team proprietario del servizio, non per imputare la colpa, ma perché, in qualità di team dedicato che gestisce il servizio, è più vicino e informato su quel servizio e sui relativi clienti.

In questi documenti sulla correzione degli errori (o COE), il team approfondisce il quadro completo di ciò che è accaduto, fornendo analisi quantitative e dati pertinenti sull'impatto dell'errore di un servizio e sul motivo per cui si è verificato. Esaminano ogni dettaglio per identificare le cause principali, inclusi tutti i fattori che contribuiscono al problema, e descrivono non solo come hanno affrontato la causa principale, ma anche le operazioni da effettuare per garantire che ciò non si ripeta, spesso aggiornando o creando nuovi meccanismi di ispezione e miglioramento continuo. Questi documenti vengono quindi mantenuti in un database ricercabile, in modo che il prezioso insegnamento possa essere condiviso fra tutte le funzioni.