Nel 1967 un informatico di nome Melvin Conway inviò un paper dal titolo “How Do Committees Invent?” all’Harvard Business Review. HBR rigettò il paper (pubblicato l’anno seguente da Datamation), ma l’idea di fondo divenne popolare, in particolare dopo essere stata riproposta da Fred Brooks (link in inglese) col nome di legge di Conway. Conway ha in seguito riassunto l’idea in questa forma:
Ogni organizzazione che progetta un sistema […] produrrà inevitabilmente un design la cui struttura riflette i rapporti interni dell’organizzazione
Melvin Conway
In inglese, Conway parla di “organization’s communication structure“. L’idea è stata quindi molto influente nella teoria del management e ha contribuito alla promozione di organizzazioni flessibili quale prerequisito per la progettazione efficiente dei sistemi. Si è sviluppata ad esempio l’idea di Inverse Conway Maneuver che suggerisce di modellare consapevolmente i team e la struttura dell’organizzazione in modo che promuovano l’architettura di sistema desiderata.
I corollari della legge di Conway non sono ristretti al campo dell’informatica e possono avere conseguenze importanti su altri domini. Come ci dicono, ad esempio, sulle dinamiche nello sviluppo di un prodotto?
Prodotti che rispecchiano le organizzazioni aziendali
L’organizzazione di un’azienda non impatta solo l’architettura tecnologica: inevitabilmente si riflette anche sui prodotti che tale architettura sostiene. Ad esempio è probabile che una realtà composta da piccoli team cross-funzionali produca piattaforme modulari e architetture basate su micro-servizi.
Generalizzando, una delle ripercussioni più severe è il rischio di pensare inside the box. A ciascun team viene attribuita una parte del prodotto, e questa divisione finisce col riflettersi nell’esperienza finale, senza tener conto dell’effettiva interazione dell’utente col prodotto nel suo complesso. Si ottimizza così una parte del prodotto a prescindere dall’impatto globale di tale ottimizzazione.
Possono poi sorgere ulteriori difficoltà organizzative, che si riflettono ulteriormente sul prodotto. L’allocazione delle risorse condivise diventa implicita, ad esempio, invece di seguire le priorità del prodotto. Ciascun team attribuisce il declino di un KPI globale agli altri team (e impugna i miglioramenti a prescindere dalla dimensione del proprio contributo). Insomma, un problema generale di allineamento tra gli obiettivi individuali e l’organizzazione nel suo insieme.
I bisogni del cliente come guida
Un esempio di azienda che ha fatto esplicitamente riferimento alla legge di Conway è Microsoft. In questa email (link in inglese), Satya Nadella annuncia la formazione di due nuovi team di sviluppo e nel concludere dice (traduzione nostra): “Per ottenere il massimo impatto dai nostri sforzi dobbiamo impegnarci a trascendere la legge di Conway. L’innovazione deve essere spinta da una profonda comprensione dei bisogni inespressi o insoddisfatti dei nostri clienti. Non possiamo permettere che i limiti della nostra organizzazione si frappongano tra noi e l’innovazione per i nostri clienti“.
Il punto di Nadella è importante: c’è un riferimento che può fornire una direzione a tutti i team, ed è il focus sul cliente e sui suoi bisogni. Questi prevalgono sulla struttura interna dell’azienda e su qualsiasi spinta alla territorialità. Se una separazione interna si mette in mezzo al raggiungimento delle soluzioni di cui i clienti hanno bisogno, siamo davanti a una separazione che deve essere sanata.
Come “trascendere la legge di Conway”
Ci sono alcuni accorgimenti pratici per assicurarsi che la struttura aziendale sia ottimizzata per servire i bisogni del cliente.
1. Lavorare con artefatti che obblighino i team di prodotto a mantenere il focus sul cliente
Amazon e a seguire molte altre aziende lavorano da tempo con il formato delle PRFAQ (link in inglese), ad esempio, per guidare lo sviluppo dei prodotti dall’incipit. Questi documenti invitano a considerare ogni iniziativa e prodotto dal punto di vista dell’esperienza degli utenti che vi interagiranno. In questo modo, la discussione con altri team è organizzata intorno a questo punto fondamentale, a prescindere dalle soluzioni che verranno implementate.
2. Definire in maniera olistica le visioni e strategie di prodotto
Se la responsabilità di un team è limitata a una parte dell’esperienza globale, non significa che la loro strategia di prodotto non possa toccare aspetti più ampi. Se vanno a toccare il lavoro di altri team, sarà necessario allineare tali strategie con i team interessati. Questo è il primo passo per abbattere confini che precedono l’esperienza del cliente – confini che forse hanno un senso nella nostra organizzazione, ma non nel modo in cui i clienti interagiscono con i nostri prodotti.
3. Utilizzare le sessioni di prioritizzazione come strumenti di condivisione e discussione
Discutere in maniera continuativa le priorità a stretto contatto con i team “limitrofi” è un modo eccellente per trovare sinergie. Invece di limitarsi a comunicare la propria roadmap e le proprie priorità, si discutono le ragioni dietro alle proprie scelte e si rimane aperti ad accogliere input. A prescindere dallo strumento utilizzato, le iniziative individuali possono essere descritte tramite user story o jobs to be done, così da mantenere la prospettiva del cliente e assicurarsi che le priorità siano innanzitutto informate dall’impatto rispetto a quest’ultima.
4. Utilizzare un framework per la misurazione del successo che favorisca l’allineamento verticale e orizzontale
La definizione di “successo” di ogni parte deve in qualche modo contribuire alla definizione di successo dell’organizzazione. Gli OKR nascono esattamente per rispondere a questa esigenza. L’idea di North Star KPI è, a mio avviso, ancora più utile per allineare aspetti specificamente di prodotto. A prescindere dal metodo, l’obiettivo è creare connessioni chiare tra il beneficio creato localmente e beneficio percepito complessivamente dall’utente.
