[La tua struttura organizzativa ha già deciso il destino del tuo software] — La legge di Conway, una legge fondamentale della gestione sottostimata per 56 anni La trasformazione dell'ingegneria del software nell'era dell'IA — Impara l'IA lentamente 171

Premessa

• La tua architettura software non è “progettata” dal tuo team tecnico, ma “cresce” dalla tua struttura organizzativa. Questa legge formulata nel 1968 viene costantemente confermata nell’era dell’IA.
• Uno studio empirico della Harvard Business School dimostra che la distanza organizzativa predice con maggiore accuratezza il tasso di difetti software rispetto alla complessità del codice. Quello che credi essere “technical debt” è, in realtà, spesso “organizational debt”.
• L’impero dei microservizi di Amazon, il modello a squadre di Spotify, la crisi di Siri di Apple — tre aziende da trilioni di dollari, destini radicalmente diversi, che illustrano la stessa legge.
• Gli AI agent stanno entrando nel tuo organigramma. Quando i “nodi” del tuo team non sono più solo esseri umani, la legge di Conway verrà riscritta in modi che non ti aspetti.

Nel 1968, un programmatore sconosciuto scrisse un articolo rifiutato dalla Harvard Business Review con la motivazione: “non ha dimostrato la sua tesi”. 56 anni dopo, l’idea centrale di quell’articolo è diventata una legge universale riconosciuta in tutta l’ingegneria del software — e nel 2026, mentre l’IA ridefinisce tutto, è più rilevante che mai.

1. Come un articolo rifiutato è diventato la “legge di gravità” dell’ingegneria del software

Il profeta respinto dalla HBR

Nel aprile 1968, Melvin Conway pubblicò sulla rivista Datamation un articolo dal titolo apparentemente banale: How Do Committees Invent? (Come inventano i comitati?).
La tesi centrale dell’articolo si riduce a una sola frase, sufficiente a tenere svegli qualsiasi CTO:

“The organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”

In parole povere: il tuo organigramma aziendale è la copia speculare del tuo architettura software.
Conway descrive nel suo articolo un caso elegante: un’azienda assegna 8 persone a due gruppi per sviluppare due compiler — un gruppo da 5 e uno da 3. Risultato? Il gruppo da 5 ha prodotto un compiler a 5 fasi; quello da 3, un compiler a 3 fasi. Non perché la tecnologia lo richiedesse, ma perché — ogni persona aveva bisogno di “possedere” la propria unità di lavoro.
Conway descrisse questa relazione in termini matematici come “omomorfismo” (homomorphism): esiste una mappatura che preserva la struttura tra l’organizzazione e il design del sistema. Non è una coincidenza, non è un caso: è una legge quasi matematicamente inevitabile.

Ironicamente, Conway inizialmente inviò questo articolo alla Harvard Business Review, ma fu rifiutato dagli editori con la motivazione che “non dimostrava la sua tesi”. Sette anni dopo, Fred Brooks citò ufficialmente questa osservazione nel suo classico “The Mythical Man-Month”, dandole il nome definitivo di “Legge di Conway”.
Da allora, un’osservazione rifiutata dai principali giornali commerciali è diventata una delle leggi più citate nell’ingegneria del software.

La “sentenza finale” di Martin Fowler

Se Conway è stato il Copernico che formulò l’ipotesi, gli ultimi vent’anni di ricerca empirica sono stati il telescopio.

Nel 2022, Martin Fowler, capo scienziato di ThoughtWorks, scrisse una valutazione ampiamente diffusa nel settore: “Se c’è una sola legge nell’architettura del software che tutti i praticanti riconoscono, è la Legge di Conway. È abbastanza importante da aver influenzato ogni sistema che ho visto; è abbastanza potente da far fallire chiunque tenti di opporvisi.”

Non si tratta di un’elaborazione teorica di uno studioso nella torre d’avorio. Fowler ha osservato ripetutamente, nei suoi interventi presso centinaia di aziende in tutto il mondo, lo stesso fenomeno: l’organigramma di un’azienda è l’ombra del suo software, indipendentemente dal fatto che la direzione se ne renda conto o meno.

C’è un significato sottile ma cruciale che molti trascurano: Fowler dice che “chiunque tenti di contrastarlo è destinato al fallimento”, non “chiunque tenti di sfruttarlo“. Qual è la differenza? Contrastare la legge di Conway significa imporre cambiamenti architetturali senza modificare la struttura organizzativa; sfruttarla, invece, significa modificare prima l’organizzazione, lasciando che l’architettura cresca in modo naturale.
Questa distinzione determina il successo o il fallimento dei progetti di trasformazione digitale. Nella nostra seconda parte, quando discuteremo Team Topologies, approfondiremo la strategia chiave dell’”Inverse Conway Maneuver” — che consiste essenzialmente nello sfruttare, non nel contrastare, questa legge.

II. Dal laboratorio al campo di battaglia: tre studi confermano questa legge

L’ipotesi dello specchio della Harvard Business School

Nel 2012, MacCormack e colleghi della Harvard Business School pubblicarono uno studio fondamentale, noto in ambito accademico come “Mirroring Hypothesis”.
Il metodo era geniale: confrontarono software commerciali e software open source che svolgevano esattamente la stessa funzione. I software commerciali erano sviluppati da team aziendali gerarchici; quelli open source da comunità diffuse e informali.

I risultati confermano la legge di Conway: i prodotti sviluppati da organizzazioni a bassa accoppiatura risultano significativamente più modulare. Team aziendali strettamente accoppiati, anche se intenzionalmente orientati verso un design modulare, producono sistemi che riflettono comunque la loro struttura organizzativa, con un alto grado di accoppiamento.

La struttura organizzativa agisce come un “campo gravitazionale”: puoi opporvi temporaneamente, ma nel lungo termine l’architettura del sistema verrà inevitabilmente attratta verso una forma isomorfa alla struttura dell’organizzazione.

Qual è l’implicazione reale per i decisori aziendali? Quando il tuo team tecnico ti ripete costantemente “dobbiamo ristrutturare”, ciò che realmente necessita di “ristrutturazione” potrebbe non essere il codice, ma l’organizzazione. Ma come distinguere tra “debito tecnico” e “debito organizzativo”? Serve un approccio sistematico di diagnosi — e nella nostra 12ª serie, Framework per l’adozione degli strumenti AI in azienda, forniremo un modello di valutazione completo.

L’“esperimento Windows Vista” di Microsoft Research

Nel 2008, Nagappan e colleghi di Microsoft Research hanno condotto uno studio quantitativo su larga scala sul progetto Windows Vista. L’obiettivo era rispondere a una domanda fondamentale: qual è il fattore che meglio predice la presenza di difetti (bug) nel software?

Le ipotesi candidate includevano: complessità del codice, numero di righe di codice, frequenza di modifica, esperienza degli sviluppatori… e una variabile che sembrava non avere alcun legame con la “tecnologia” — la distanza organizzativa (cioè la distanza gerarchica tra i team che sviluppano moduli correlati).

Le conclusioni dello studio hanno turbato molti tecnocratici: la distanza organizzativa predice con maggiore precisione il tasso di difetti software rispetto alla complessità del codice. In altre parole, un modulo sviluppato da due team “lontani” nell’organigramma ha maggiori probabilità di contenere bug rispetto a un modulo estremamente complesso ma mantenuto da un team strettamente collaborativo. Pensavi che i bug fossero causati da codice scritto male: in realtà potrebbero essere il risultato di una cattiva progettazione organizzativa.

Questa scoperta ha implicazioni aziendali molto più profonde di quanto appaia in superficie: la tua strategia QA deve seguire l’architettura organizzativa, non la complessità del codice. I moduli sviluppati da team diversi richiedono una copertura di test più rigorosa e processi di revisione più stringenti, anche se il codice in sé sembra semplice. Oggi, con l’esplosione del codice generato dall’IA (Copilot genera ora il 46% del codice scritto dagli utenti), questo principio è diventato ancora più cruciale — lo approfondiremo nel dettaglio con il caso di Coinbase nella 8ª parte, quando discuteremo il “paradosso della produttività”.

L’”accelerazione” e le “preoccupazioni nascoste” dello studio DORA

Il team DevOps Research and Assessment (DORA), guidato da Nicole Forsgren, Jez Humble e Gene Kim e appartenente a Google, ha pubblicato lo studio più ampio mai condotto sull’efficacia della consegna del software.

La scoperta principale è in forte allineamento con la Legge di Conway: “Se implementiamo un’architettura a basso accoppiamento e ben incapsulata, accompagnata da una struttura organizzativa corrispondente, possiamo non solo accelerare il ritmo di consegna e migliorare la stabilità, ma anche mantenere una crescita della produttività lineare o addirittura superlineare anche quando il team di ingegneria si espande notevolmente.” Tuttavia, il rapporto DORA del 2022 ha rilevato un effetto collaterale sorprendente: sebbene l’architettura a basso accoppiamento migliori l’efficienza di consegna, può aumentare il burnout dei team. La ragione potrebbe essere questa: quando i team sono altamente autonomi e isolati gli uni dagli altri, i membri perdono la percezione del senso complessivo, sviluppando un senso di isolamento del tipo “Sono solo un ingranaggio”.

Questo è un importante promemoria — l’allineamento tra architettura e organizzazione non è una panacea: risolve problemi di efficienza, ma può generare problemi culturali. Un’implicazione profonda: se un’architettura a basso accoppiamento + un’organizzazione a basso accoppiamento già fanno sentire gli sviluppatori umani isolati, cosa succede quando ai team si aggiungono agenti AI? L’AI non “si sente isolata”, ma gli umani diventano ancora più isolati. Questo aspetto è raramente discusso, ma nei materiali che abbiamo studiato, un rapporto BCG del 2025 introduce il “dilemma di orchestrazione dei manager di medio livello” — proprio il tema centrale della nostra undicesima analisi.

3. I “momenti Conway” di tre aziende da mille miliardi

Amazon: una mail del CEO che ha cambiato tutto

Intorno al 2002, Jeff Bezos ha inviato all’interno di Amazon il famoso “API Mandate”: tutti i team dovevano comunicare esclusivamente tramite interfacce di servizio (API), vietando categoricamente l’accesso diretto ai datastore degli altri team.
L’ultimo punto di questa email sarebbe stato: “Chi non rispetterà queste regole verrà licenziato.”
Molti considerano l’architettura a microservizi di Amazon una scelta tecnica. Ma secondo la legge di Conway, Bezos ha compiuto in realtà una decisione organizzativa: ha prima imposto con mezzi manageriali l’interruzione delle “shortcuts comunicative” tra team, e l’architettura software si è evoluta naturalmente in moduli di servizio isolati.

Questo ha portato alla successiva formulazione da parte di Bezos del concetto di “Two-Pizza Team”: ogni team non doveva superare la dimensione che due pizze potevano sfamare (tipicamente 5-8 persone), ciascuno con il proprio servizio, distribuito in modo autonomo e che interagiva con l’esterno esclusivamente tramite API.
L’impero dei microservizi di Amazon non è stato progettato da architetti, ma è cresciuto organicamente grazie alla struttura organizzativa. È il caso più classico e positivo della legge di Conway.

Ma qui c’è un aspetto che molti articoli non menzionano: il successo del modello di Amazon non dipende solo dal fatto che Bezos abbia compreso la legge di Conway, ma anche dal fatto che abbia risolto contemporaneamente il problema dell’allineamento degli incentivi. Ogni “team due pizza” possiede il proprio P&L (conto economico), ed è autonomo non solo dal punto di vista tecnico, ma anche da quello commerciale. Ciò significa che i team hanno un incentivo intrinseco a mantenere chiari i confini dei servizi — perché confini ambigui implicano responsabilità ambigue, e responsabilità ambigue implicano valutazioni ambigue. L’allineamento triangolare tra struttura organizzativa, struttura degli incentivi e architettura tecnica costituisce l’intera visione del modello Amazon. Le aziende che imitano solo la struttura organizzativa, senza copiare il design degli incentivi, ne catturano spesso la forma, ma non la sostanza.

Spotify: il modello ideale scontrato con l’“aumento di entropia” della realtà

Il modello “Squad” di Spotify è stato un tempo considerato la bibbia del design organizzativo a Silicon Valley: piccole squadre autonome di 5-8 persone (Squad), raggruppate in tribù (Tribe), esperti tecnici trasversali riuniti in capitoli (Chapter), e comunità guidate dall’interesse condiviso chiamate gilde (Guild).

Il pensiero alla base di questo modello è altamente coerente con la legge di Conway — attraverso strutture organizzative piccole e autonome, si promuove l’emergenza di servizi software altrettanto piccoli e autonomi.

Ma Spotify stessa ha poi ammesso che la realtà è molto più complessa del modello. Quando l’azienda cresce fino a una certa scala, le dipendenze tra team diventano inevitabili, e l’autonomia pura inizia a generare costi di coordinamento.
Questo rivela un’implicazione spesso trascurata della legge di Conway: la struttura organizzativa non è qualcosa che si progetta una volta per tutte; come il software, ha una tendenza all’aumento dell’entropia. Man mano che la complessità aziendale cresce, i confini organizzativi si sfumano, i percorsi di comunicazione si allungano, e l’architettura del sistema ne risulta degradata.
Un’organizzazione tecnologica eccellente non è “quella che ha progettato una buona architettura”, ma quella che ha costruito la capacità di allineare continuamente organizzazione e architettura. Questa capacità la approfondiremo nel secondo articolo sulle Team Topologies — che offre un framework più sistematico e operativo rispetto al modello Spotify.

Apple: Perché Siri è stata “battuta” da ChatGPT

Nel 2024-2025, il piano di aggiornamento AI di Siri di Apple è diventato quasi un “controesempio” della legge di Conway.

La radice del problema non è tecnica. Apple possiede talenti di ricerca AI di prim’ordine e risorse finanziarie abbondanti. Ma lo sviluppo di Siri coinvolge due team con una frattura strutturale nell’organizzazione: il team di ricerca AI (guidato da John Giannandrea) e il team di sviluppo prodotto (guidato da Craig Federighi).

I due team hanno priorità diverse, ritmi diversi, criteri di successo diversi. Il team di ricerca AI cerca di spingere i confini delle capacità dei modelli; il team prodotto mira a consegnare un’esperienza utente stabile. Quando la struttura di comunicazione tra questi due “nodi” organizzativi è frammentata, il sistema risultante è inevitabilmente frammentato.

Cosa ottengono gli utenti finali in Siri? Un “assistente mediocre, un insieme di funzionalità拼凑” — ogni modulo sembra funzionare bene da solo, ma insieme manca di un’esperienza intelligente coerente. Questo è esattamente il risultato previsto dalla legge di Conway: le crepe nel sistema riflettono le crepe nell’organizzazione.

Il caso di Apple merita particolare attenzione dai decisori cinesi. Molte aziende stanno vivendo esattamente lo stesso problema — i team AI e i team business sono sotto VP diversi, e i progetti di implementazione AI diventano “un gioco politico tra due dipartimenti”, anziché “un rilascio coordinato di un prodotto”.

Se la tua azienda sta spingendo l’adozione dell’IA, guarda indietro al tuo organigramma: le capacità di IA sono gestite da un dipartimento indipendente o sono integrate nei team operativi? La risposta a questa domanda potrebbe determinare il successo o il fallimento del progetto più della scelta del modello di IA.

4. L’era dell’IA: La legge di Conway sta essendo riscritta

Quando i “nodi organizzativi” non sono più solo umani

Nel 2026, la legge di Conway affronta la sua sfida più profonda dal 1968.
Conway, nel formulare questa legge, assumeva un presupposto implicito: ogni “nodo” nell’organizzazione è un essere umano. La struttura di comunicazione è quella tra persone.

Ma oggi, gli agenti di IA stanno entrando nell’organigramma. Claude Code completa autonomamente compiti di sviluppo multi-passo; il sistema Minions di Stripe genera oltre 1.000 PR fusionati a settimana; Cursor ha trasformato il modo di lavorare del 100% degli ingegneri di NVIDIA. Secondo Gartner, le richieste di consulenza sulle orchestrazioni multi-agente di IA sono aumentate del 1445% nel 2025.

Cosa succede alla legge di Conway quando alcuni nodi nell’organizzazione non sono più umani?

La discussione su questo tema attraverserà la seconda metà di tutta la nostra serie — l’articolo 10 sul fenomeno “Solitario Unicorn”, l’articolo 11 su “La legge di Conway incontra gli AI agent”, l’articolo 14 su “Agentic Engineering” — ma qui forniamo tre giudizi preliminari per costruire il tuo quadro concettuale:

Primo, la struttura di comunicazione diventerà una struttura di strategia. La comunicazione tra esseri umani dipende da cultura, intesa e interazioni informali. Ma tra esseri umani e AI agent non esiste “intesa” — devi definire i confini dell’interazione attraverso strategie, regole e permessi espliciti. La capacità di governance sostituirà la capacità di comunicazione come variabile centrale nel design organizzativo.

Secondo, il diagramma organizzativo diventerà un diagramma di permessi. I tradizionali diagrammi organizzativi descrivono relazioni di subordinazione e divisione delle funzioni. Nell’era dell’AI, il “diagramma” assomiglia piuttosto a un grafo orientato aciclico (DAG) che definisce capacità e vincoli: quale agent può accedere a quali dati, eseguire quali operazioni e in quali condizioni richiedere l’approvazione umana.

Terzo, la conoscenza istituzionale passerà dalle persone alle strategie. In passato, “quando un dipendente esperto se ne va, porta via la conoscenza” era una sofferenza comune a ogni azienda. Nel futuro, la conoscenza chiave sarà codificata nelle strategie e nel contesto degli AI agent — questa è sia un’opportunità (la conoscenza non si perde più) che un rischio (un errore nella strategia potrebbe amplificarsi in modo sistematico).

Ogni giudizio è supportato da numerose pratiche industriali e dati. Ad esempio, il terzo punto riguardante “il trasferimento della conoscenza istituzionale” offre un esempio drammatico sia positivo che negativo: dopo aver licenziato il 40% dei dipendenti, Klarna ha scoperto che il sistema AI non riusciva a sostituire le conoscenze implicite portate via dai dipendenti licenziati, costringendoli a ricontrattarli. Questa storia verrà esaminata in dettaglio nel nostro nono articolo, “Le Lezioni di Klarna”.

La prima e la seconda affermazione non sono sole nostre. Nell’episodio del podcast a16z del luglio 2026, Software in the Age of Agents, Seema Amble, partner del team enterprise di a16z, e Steven Sinofsky, ex CEO di Windows Microsoft, hanno raggiunto conclusioni altamente allineate partendo dalla loro osservazione diretta sugli investimenti. Steven ha sintetizzato il cuore della prima affermazione in una frase: “The biggest network effect in enterprise software is inside of a company”: la rete composta da relazioni umane, processi e sistemi all’interno di un’organizzazione è l’elemento vero e proprio di stickiness. Gli agent non possono accedere a questa rete per “intesa” — devono farlo attraverso strategie e permessi espliciti: questa è la spinta pratica che trasforma la struttura di comunicazione in una struttura di strategia. Seema ha confermato la seconda affermazione dal punto di vista dell’accesso degli agent ai sistemi aziendali: quando un agent deve “eseguire” (scrivere su registri, modificare contabilità), si scontra immediatamente con un intero sistema di identità, credenziali, posti fatturabili e autorizzazioni di approvazione — l’organigramma sta diventando una mappa di permessi: “chi può accedere a cosa, chi autorizza cosa”. Queste due affermazioni non sono previsioni: sono fatti già in corso nei progetti in cui gli investitori di prima linea stanno mettendo i loro fondi. (Ospiti: partner a16z / ex executive Microsoft, posizione VC.)

Cinque: Autovalutazione a confronto: quale “errore di Conway” sta commettendo la tua organizzazione?

Se hai letto fino a qui e pensi ancora “ho capito tutto questo”, ti invito a fare un esercizio.

Di seguito riportiamo cinque modelli comuni di “disallineamento organizzativo-architetturale”, ricavati dalla legge di Conway e dai suoi studi successivi. Confrontali con la tua azienda e vedi quante di queste ti risuonano:

• ❶ Microservizi superficiali: Il codice è stato diviso, ma 50 persone continuano a litigare nello stesso gruppo.
• ❷ Illusione del middleware: Il middleware è diventato il collo di bottiglia per tutte le linee di business.
• ❸ Isola AI: I modelli prodotti dal team AI non possono essere integrati nei processi aziendali, perché a livello organizzativo “vanno su strade diverse”.
• ❹ Deterioramento della collaborazione remota: L’isolamento fisico ha causato frammentazioni sistemiche non necessarie.
• ❺ Difficoltà di integrazione post-acquisizione: Il fallimento nell’integrazione tecnica causato da incompatibilità culturali organizzative.

Prossimo passo

Questo è il primo di 15 articoli della serie “La trasformazione dell’ingegneria del software nell’era dell’IA”. Partendo dalla legge di Conway, abbiamo costruito una consapevolezza fondamentale: l’architettura organizzativa determina l’architettura del sistema — non è una metafora, ma una relazione causale verificata empiricamente.

Ma conoscere questa legge è solo l’inizio. La vera domanda è: possiamo sfruttarla al contrario? Progettare intenzionalmente l’organizzazione per guidare l’architettura di sistema desiderata — è questo il cuore dell’“Inverse Conway Maneuver”.
Nel prossimo articolo, “Team Topologies — Una metodologia di progettazione organizzativa nell’era post-Agile”, esploreremo come Matthew Skelton e Manuel Pais abbiano trasformato questa idea in un framework completo e operativo, includendo quattro tipi fondamentali di team, tre modelli di interazione e il concetto di “cognitive load”, spesso sottovalutato. Casi d’uso di aziende come Netflix, Adidas e Accenture dimostreranno in quali condizioni l’Inverse Conway Maneuver funziona — e in quali fallisce.

Nota sulla serie: Questa serie seguirà costantemente l’evoluzione degli strumenti di programmazione AI, delle architetture organizzative e dei paradigmi di ingegneria del software, come i nuovi sviluppi della legge di Conway nell’era degli AI agent (2026) e la maturità dell’ecosistema degli strumenti più recenti. Segui la serie per ottenere insight aggiornati in tempo reale.

About this series

La rivoluzione dell’ingegneria del software nell’era dell’IA è una serie di approfondimenti rivolta ai decisori tecnologici aziendali, composta da 15 articoli. Basata su uno studio sistematico di oltre 200 articoli accademici e report di settore, ti offre riferimenti decisionali con annotazioni sui livelli di evidenza. Altri contenuti in arrivo.

Fonti di riferimento:

• Conway, M. (1968). How Do Committees Invent? Datamation, 14(4), 28–31.
• Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
• MacCormack, A., et al. (2012). Exploring the Duality between Product and Organizational Architectures: A Comparative Study of Commercial and Open Source Software. Harvard Business School Working Paper.
• Nagappan, N., et al. (2008). The Influence of Organizational Structure on Software Quality. ICSE ‘08 Proceedings.
• Forsgren, N., et al. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
• Fowler, M. (2022). Conway’s Law. martinfowler.com/bliki/ConwaysLaw.html.
• Gartner (2025/26). Predicts 2026: AI Agents in Software Engineering.
• a16z (2026). Software in the Age of Agents. The a16z Podcast. (Steven: “The biggest network effect in enterprise software is inside of a company”; Seema Amble sull’accesso degli agenti ai sistemi aziendali e gli ostacoli legati a permessi, credenziali e licenze — supportano le affermazioni 1 e 2 della sezione 4; fonte primaria: audio originale del podcast. Posizione: partner a16z / ex executive Microsoft. Ospiti verificati: Seema Amble, partner dell’team enterprise di a16z; Steven Sinofsky, ex CEO di Windows e board partner di a16z; Elena Burger, redattrice di a16z; trasmesso luglio 2026.)