Prima dell’AI, rimetti i team in asse col flusso di valore

Prima di far entrare l’AI in azienda c’è una mossa che rende più di qualsiasi strumento o modello possiate scegliere: riportare i team tecnici sull’asse del flusso di valore. Ho visto fin troppe imprese comprare gli strumenti, deployare i modelli, formare le persone — e la consegna continua ad arrancare, mentre la gente esce più stanchi di prima. La causa di fondo quasi mai è un’AI troppo debole. È che i team sono tagliati a strati tecnologici — frontend, backend, algoritmi, ops, sicurezza. Una funzionalità end-to-end deve attraversare quattro, cinque team, e a ogni passaggio si perde qualcosa. Un pezzo di requisito. Un pezzo di contesto. Un pezzo di responsabilità. Metti i confini giusti, e l’AI trova terreno dove amplificarsi. Lasciali sbagliati, e l’AI accelera soltanto il debito su una struttura rotta.

L’articolo presenta un metodo di design organizzativo che si può davvero usare — Team Topologies (Skelton & Pais, 2019). Tre idee al centro: tagliare i team sul flusso di valore, tenere d’occhio il carico cognitivo di ciascun team, gestire la piattaforma interna come un prodotto. Lo smonto attraverso uno scenario reale del manifatturiero.

Un CIO di industria (caso anonimizzato da un progetto vero) mi raccontava: avevano lanciato una funzione di ispezione qualità intelligente. La tecnica non era difficile — telecamere che rilevano i difetti, modello già disponibile. Il difficile era la consegna. Il team frontend faceva l’interfaccia, il team MES modificava il flusso degli ordini di lavoro, il team algoritmi deployava il modello, il team ops gestiva i server, e sopra a tutto la sicurezza doveva fare la sua revisione. Una funzione, 5 team, 4 passaggi formali, 3 mesi di strascico. Nessuno poltriva. Semplicemente, a ogni passaggio cadeva qualcosa per terra.

1. La legge di Conway racconta solo metà della storia

La legge di Conway dice: l’architettura di un sistema riflette la struttura di comunicazione del team che lo costruisce. Dividi i team in frontend e backend, e ottieni un sistema spaccato in frontend e backend. Come comunica il team, così cresce il sistema. L’evidenza lo ha confermato ancora e ancora.

Però Conway si è fermato a “andrà così”. Non ha detto come progettare i team perché la buona architettura cresca da sola. Skelton e Pais hanno chiuso quel varco con Team Topologies (2019): quattro tipi fondamentali di team, tre modalità di interazione, e un principio che attraversa tutto — tenere d’occhio il carico cognitivo.

2. I quattro tipi di team: opzioni per una riorganizzazione, non termini da mandare a memoria

Li presento come “opzioni che puoi richiamare durante una riorganizzazione”, non come definizioni da imparare a memoria.

Stream-aligned team — il cavallo da tiro dell’organizzazione, e la stragrande maggioranza. (Il libro dice “most”, senza fissare una percentuale.) Uno “stream” è un flusso continuo di valore. Lo stream-aligned team possiede un tratto di quel flusso end-to-end: capire il requisito, costruirlo, rilasciarlo, mandarlo in produzione. Un solo test basta a dirti se un team è stream-aligned: può portare valore nelle mani dell’utente senza dipendere da un altro team? Torniamo al CIO: se la sua funzione di ispezione intelligente fosse stata di un solo “team del flusso qualità” — con dentro chi conosce il frontend, chi l’integrazione MES, chi il deploy dei modelli, chi le ops — la funzione sarebbe partita con zero passaggi. È questa la forma che dovrebbe avere.

Il problema più diffuso nelle grandi imprese è che il sistema corre end-to-end mentre i team sono tagliati in strati tecnologici orizzontali. Ogni consegna end-to-end deve infilarsi nei confini di reporting di più team. Cambia settore, e il vizio resta. Nel finanziario è la funzione di risk management del credito a dover attraversare quattro gruppi — App, sistema core, modelli di rischio, dati — con App che entrega l’esperienza cliente, il core che chiude i conti, i modelli di rischio che devono dare il loro punteggio e la piattaforma dati che alimenta tutto; quattro team, quattro backlog, quattro sprint separati, e il rischio di credito che cade nelle crepe tra l’uno e l’altro. E-commerce e telecom compressano lo stesso dolore in parole diverse: una promozione attraversa catalogo, transazioni, marketing, magazzino; un cambio di piano tariffario attraversa canali, billing, CRM, rete. Quando i team tagliati in orizzontale devono servire un flusso di valore che corre in verticale, i passaggi moltiplicano. È la malattia.

Platform team — spiana la strada agli stream-aligned team. Fornisce infrastruttura, CI/CD, servizi condivisi, così gli stream-aligned team possono servirsi da soli invece di aprire un ticket e aspettare. Un test: la tua piattaforma interna è gestita come un prodotto — con utenti, roadmap, SLA — o è scivolata nel ruolo di “outsourcing interno” che vive di ticket? La maggior parte degli IT delle grandi imprese è incastrata nella seconda. Costruiscono una piattaforma che nessuno usa, i team di business la aggirano e si fanno i fatti propri, e il platform team degrada a fornitore esterno interno. Spinnaker di Netflix (continuous delivery) e Backstage di Spotify (developer portal) sono i casi da manuale di piattaforma gestita come prodotto. Li confondono di continuo: Spinnaker è di Netflix, Backstage è di Spotify. Non scambiarli davanti al board.

Enabling team — aiuta gli stream-aligned team a salire di livello, con il fine esplicito di mettersi fuori gioco. Non consegna direttamente valore di business. Alza le capability degli stream-aligned team: un coach che introduce una tecnologia nuova, una guida per la transizione DevOps, un consulente su sicurezza e compliance. Il rapporto con lo stream-aligned team è tra mentore e allievo, non tra cliente e fornitore. Per le grandi imprese, questo è il ruolo che un consulente esterno di trasformazione dovrebbe giocare — trasferire capacità, non costruire dipendenza a lungo termine.

Complicated-subsystem team — per i problemi duri che chiedono specializzazione profonda. Quando un sottosistema esige profondità vera — un motore di rischio, un algoritmo di raccomandazione, crittografia, codec video — lo stacchi come team di esperti a sé, invece di far esplodere il carico cognitivo di uno stream-aligned team. Dovrebbero essere rari. Un’organizzazione che si ritrova con molti complicated-subsystem team, di solito ha trasformato in silos quella che sarebbe dovuta diventare capacità di piattaforma.

Distinguere i tipi di team non basta. Bisogna anche definire come si parlano tra loro. Team Topologies dà tre modalità di interazione. Collaborazione — due team che lavorano a fondo insieme, adatta a territori nuovi e incerti, ma ad alto consumo di energie e solo per brevi periodi. X-as-a-Service — un team offre una capacità come prodotto che un altro team consuma da solo; è la modalità più efficiente e dovrebbe essere il default. Facilitating — riservata agli enabling team. La domanda chiave del design organizzativo è come spingere quante più interazioni possibile verso X-as-a-Service. Se a lungo termine si vive di “collaborazione”, la piattaformizzazione non è avvenuta. Prendi il CIO: tra il team del flusso qualità e il platform team dovrebbe esserci X-as-a-Service. La piattaforma espone un’entrata CI/CD self-service, e il team qualità la usa senza dover avvisare. Se ogni deploy richiede ancora di riunire il platform team in una “collaborazione”, la piattaformizzazione manca — e il problema non è l’atteggiamento. È che la piattaforma non è mai stata gestita come prodotto.

3. Perché “aggiungere persone” e “aggiungere processo” non risolvono nulla: il carico cognitivo

È il contributo più sottovalutato di Team Topologies. Mette il carico cognitivo al centro del design organizzativo.

Un team di 5-8 persone ha un carico cognitivo finito. Chiedi a un team di mantenere una dozzina di sistemi scollegati, interfacciarsi con sei-sette upstream e destreggiarsi tra tre framework nuovi — va in sovraccarico. La qualità scende. La consegna rallenta. Le persone bruciano.

Questo spiega un altro interrogativo del CIO: “Ho aggiunto tre persone, perché siamo ancora lenti?” La radice è che quel gruppo portava già troppa roba non correlata. Le persone bastavano. Aggiungerne altre mette solo più teste a girare a vuoto nello stesso caos. Aggiungere processo è peggio: il processo si mangia un altro strato di carico cognitivo, e chi potrebbe davvero spedire finisce a passare più tempo su moduli, riunioni, approvazioni.

Il grasso che una grande enterprise taglia più facilmente è il carico che si auto-infligge — attrito tra team, context-switching continuo, catene di approvazione. Tagliarlo non chiede nessuna nuova tecnologia. Chiede meno agitazione.

Un caso concreto. Il responsabile di un team di sistema core in una banca aveva 7 persone interfacciate con quattro upstream — rischio, customer service, reporting regolamentare, marketing — e manteneva tre moduli tra loro sconnessi. Solo per gestire le controfirme tra team, gli allineamenti e i salti di contesto, il team consumava quasi metà delle proprie energie ogni giorno. Dia a questo team il miglior strumento AI sul mercato, e non attacca. Non hanno più banda cognitiva disponibile per imparare qualcosa di nuovo o cambiare modo di lavorare. Per salvarli, prima si alleggerisce: si staccano i moduli non correlati e il team possiede un solo flusso di valore.

La regola del Two-Pizza Team di Amazon parla di costo di comunicazione — quando le persone crescono, il numero dei canali di comunicazione tra membri (n(n-1)/2) esplode e le decisioni rallentano. Team Topologies va uno strato più in profondità: oltre le 8 persone circa, anche il carico cognitivo sfugge di mano. Quello che il design organizzativo sta davvero facendo è dividere i team in base al carico cognitivo, in modo che il carico di ciascuno cada in un intervallo sopportabile — non disegnare linee di reporting per funzione.

Un check-up in una frase per le grandi imprese: i vostri “più impegnati” portano ciascuno più di 5 cose non correlate in contemporanea? Se sì, nessuna aggiunta di persone o di processo vi salva. Dovete ridividere.

4. Come agire: l’Inverse Conway Maneuver

È la mossa più operativa del libro. Non disegnare prima l’architettura e poi riorganizzare i team per farla combaciare. Cambia prima la struttura dei team, e lascia che l’architettura cresca nella forma che vuoi.

L’approccio tradizionale ha un architetto che disegna un’architettura obiettivo (“andiamo sui microservizi!”) e poi pretende che i team si riadattino. Quasi sempre fallisce. La struttura dei team esistente continua a riportare l’architettura alla propria forma. La legge di Conway, all’opera.

L’Inverse Conway Maneuver inverte l’ordine. Riorganizza prima i team sui flussi di valore — ritaglia gli stream-aligned team, alza un platform team — così che i confini dei team diventino i futuri confini dei servizi. Poi l’architettura converge da sola verso una scomposizione di servizi sensata, perché i team comunicheranno naturalmente via API invece di allungare le mani su un database condiviso.

Torniamo al CIO. Non gli ho fatto scegliere un framework per microservizi. Gli ho fatto fare una cosa molto più terra-terra: costituire il flusso “qualità” come team a sé stante. Tirare fuori una persona ciascuno dal team frontend, MES, algoritmi, ops. Sei persone, in possesso della funzione qualità end-to-end. In tre settimane sono successe tre cose. Settimana uno: hanno scoperto che un passaggio bloccato nel flusso degli ordini MES in realtà non richiedeva affatto il team algoritmi — l’hanno risolto dentro il team. Settimana due: hanno deciso da soli di spostare il deploy del modello da “in coda per il team ops” a self-service interno, perché il platform team aveva aperto per loro un’entrata CI/CD self-service. Settimana tre: hanno rilasciato la prima piccola funzione end-to-end, senza attraversare alcun confine di team. Nessuna testa in più, nessuno strumento cambiato — gli strati orizzontali erano stati tagliati di nuovo in flussi verticali. Il ciclo di consegna è crollato da 3 mesi a 3 settimane. C’è stato anche un guadagno inatteso: questo team ha iniziato a proporre miglioramenti da solo, perché per la prima volta vedeva il quadro intero del proprio flusso ed era responsabile del risultato end-to-end. Prima, quando il lavoro attraversava 5 team, nessuno si sentiva responsabile dell’intero flusso qualità.

Per i decisori, è una conclusione controintuitiva ma ad alta leva: smetti di tormentarti sul diagramma di architettura e inizia a tagliare l’organigramma. L’architettura è il risultato. L’organizzazione è la leva.

Chi la usa

Bancario (settore focale ufficiale di TT + riferimento per la forte regolamentazione). teamtopologies.com tiene una colonna di esperti, “When DORA metrics meet governance in banking”. La ricerca DORA che cita è netta: le approvazioni esterne (external approvals) correlano negativamente con lead time, deployment frequency e restore time — più approvazioni a posteriori tra team hai, più la consegna rallenta e più la ripresa dopo un guasto è lenta. È esattamente la tesi di questo articolo: costruire la compliance dentro il team di flusso e spostare l’approvazione a monte, invece di contare su controfirme a posteriori tra team. ClearBank e altre banche digitali britanniche ricorrono spesso nell’ecosistema ufficiale. Il bancario è lo scenario più istruttivo per una riorganizzazione del flusso di valore sotto forte regolamentazione.
Zalando (e-commerce, caso da manuale di piattaforma come prodotto). La sua piattaforma interna per sviluppatori serve come capacità self-service per gli stream-aligned team — un benchmark di piattaformizzazione che la community TT cita spesso.
AutoTrader UK (annunci auto). Caso di adozione reale che TT cita ripetutamente — riorganizzazione per flusso di valore + prodottizzazione della piattaforma interna.
KPMG UK (diventata partner ufficiale delle soluzioni TT nel 2024). Porta TT a clienti enterprise e finanziari — un segnale che TT è entrato nella consulenza aziendale mainstream.
Netflix / Spotify (casi spirituali di “piattaforma come prodotto”, non adozioni di TT). Entrambi gestivano le piattaforme come prodotti ben prima che il libro TT uscisse nel 2019, confermando il principio — ma non sono adozioni del modello a quattro team di TT.

Riferimenti: teamtopologies.com/examples (raccolta casi ufficiale) · teamtopologies.com/news-blogs-newsletters/when-dora-metrics-meet-governance-in-banking (colonna esperta DORA per il bancario)

5. Quando non funziona

Team Topologies non è un proiettile d’argento. Quattro modi comuni di fallire, ciascuno specchio di una patologia reale delle grandi imprese.

Cambiare il nome, non la struttura. Ribattezzare il “team frontend” come “stream-aligned team” lasciando le linee di reporting sullo strato tecnologico — la legge di Conway non si paga la nomenclatura. È l’esito più frequente delle riforme “vestito nuovo, stessa medicina” nelle grandi imprese.

Il platform team non gestito come prodotto. Niente roadmap, niente esperienza utente. Gli stream-aligned team continuano a aggirarlo, e la piattaforma degrada a outsourcing che vive di ticket.

Tutti in “collaborazione”. La collaborazione è un’interazione ad alta energia, adatta solo a brevi picchi in territori nuovi e incerti. Affidarcisi a lungo termine significa che la piattaformizzazione non c’è. La superficie sembra “bellissima cultura collaborativa”. Il male è la piattaformizzazione mancante.

I KPI non hanno seguito. L’organigramma è cambiato, ma misuri ancora per funzione — righe di codice frontend, numero di bug — e il comportamento dei team scatta indietro alla forma vecchia.

Queste quattro rigano un giudizio: struttura organizzativa, struttura degli incentivi e architettura tecnica — cambiarne una senza che le altre due seguano, e la trasformazione fallisce.

Una variante per i settori fortemente regolamentati. Finanza e telecom si chiedono: funzioni come sicurezza, compliance e rischio tecnologico, la regolamentazione ne vuole l’indipendenza (segregation of duties), e non possono essere semplicemente assorbite nello stream team. È un vincolo legale, non inerzia organizzativa — non smontarlo con la forza. Ma non serve nemmeno tornare alle code di approvazione orizzontali. Due strade. Prima: incorporare nello stream team un referente di compliance/sicurezza — siede nel team, con reporting tratteggiato alla funzione compliance, vicino al flusso di valore e tuttavia indipendente. Seconda: configurare la compliance come enabling team, aiutando gli stream team a costruire i requisiti regolamentari nel flusso — controlli di compliance dentro la CI, per dire — spostando l’approvazione all’interno del team invece di contare su controfirme a posteriori tra team. Il requisito regolamentare diventa qualità integrata dello stream team, non un cancello di revisione esterno. È la chiave perché i settori fortemente regolamentati riescano a “far scorrere”.

6. Potresti chiederti

“Siamo tagliati a strato tecnologico da dieci anni — una riorganizzazione non ci farà a pezzi?” Sì, ma molto meno di quanto pensi. Non devi buttare all’aria tutta l’azienda e ricominciare. Scegli il flusso di valore più bloccato — di solito quello di cui tutti si lamentano più forte — e alzalo come stream-aligned team pilota. Come quel CIO: 4-8 settimane, un piccolo team, e vedi uno scatto netto nella velocità di consegna. Lascia che i risultati vendano il giro successivo — funziona molto meglio di una slide deck.

“Che rapporto ha con la trasformazione AI che sto già portando avanti?” Diretto. L’AI non ripara un’organizzazione mal configurata. Amplifica le condizioni esistenti: i team ad alte prestazioni con l’AI diventano più veloci; i team mal configurati con l’AI producono solo debito più in fretta. Quindi la diagnosi organizzativa viene prima dell’acquisto degli strumenti. È anche il motivo per cui ho messo la “valutazione delle capacità” molto presto nel mio metodo di firma, il 7-Step AI Transformation Coaching Framework — prima guardi l’organizzazione e le persone, poi parli di strumenti.

“Non riusciamo a mettere in campo tutti e quattro i tipi di team.” La maggior parte delle organizzazioni non ci riesce, e non deve. I primi due che ti servono sono gli stream-aligned team (per garantire la consegna end-to-end) e il platform team (per smettere di reinventare la ruota). Enabling e complicated-subsystem team entrano a bisogno; molte organizzazioni non li hanno all’inizio, ed è sano. Non fabbricare team per completare i quattro tipi. Sarebbe la coda che muove il cane.

7. Lezioni per i decisori

Lezione uno: prima di far entrare l’AI, disegna una mappa di team topology. Prima di introdurre l’ultimo strumento AI, avevi mai disegnato la tua team topology? Con i team tagliati a strato tecnologico, per quanto l’AI sia forte, stai solo accelerando il debito su una struttura rotta. Questo solo controllo può bloccare almeno metà degli investimenti IT sprecati in una grande impresa. Azione concreta: elenca tutti i team e segna quale flusso di valore ciascuno possiede end-to-end. Quelli che non riesci a segnare sono tagliati a strato tecnologico, e sono la priorità di riorganizzazione.

Lezione due: fai un check-up del carico cognitivo. Smetti di chiedere “abbiamo abbastanza persone”. Chiedi quali team mantengono più di 5 sistemi non correlati in contemporanea, e quali persone interfacciano con più di 3 upstream. Far emergere questi dati è molto più utile di aggiungere teste o processo. L’AI può assorbire una parte del carico — scrivere codice, cercare informazioni, triage in prima battuta — a patto che tu riallochi il carico in modo deliberato, invece di rovesciare un’ulteriore attività “rollout AI” su un team già sovraccarico.

Lezione tre: gestisci la piattaforma interna come un prodotto, o diventerà inevitabilmente outsourcing. La piattaforma deve avere utenti, roadmap, SLA e qualcuno responsabile dell’adozione. Nell’era dell’AI, questa piattaforma deve anche assorbire il model gateway, la prompt library e l’agent runtime — è la base che il prossimo pezzo sul “framework di adozione” svilupperà.

Lezione quattro: non lasciare che l’AI indurisca i confini sbagliati. Questa è dedicata alle organizzazioni che introducono agent AI. Quando aggiungi agent AI nei team, un taglio sbagliato viene amplificato: l’agent automatizzerà lungo i confini attuali — sbagliati — consolidando la struttura rotta. Prima di introdurre agent AI, conferma che i confini dei team siano giusti. È il focus dell’undicesimo pezzo della serie.

Autoverifica (rispondi senza abbellire): i tuoi team sono tagliati sul flusso di valore, o su frontend/backend/ops/sicurezza? La persona più impegnata porta più di 3 cose non correlate in contemporanea? Se la tua piattaforma interna non ha utenti, è il semaforo rosso di una piattaformizzazione fallita. Se una qualunque di queste ti fa esitare, allora prima di far entrare l’AI riorganizza i team. È la mossa preliminare con il rendimento più alto che tu possa fare.

Prossimo passo

Questo è il secondo pezzo della serie “La trasformazione dell’ingegneria del software nell’era dell’AI” (numero 172 della rubrica “Learn AI Slowly”). Siamo andati da Conway (l’organizzazione decide l’architettura) a Team Topologies (come progettare l’organizzazione). Il prossimo pezzo (il terzo) prende una domanda più di fondo: quando l’AI rende la produzione di codice quasi gratuita, dove si sposta il collo di bottiglia dell’ingegneria del software?

Nota sulla serie: questa serie continua a seguire l’evoluzione più recente di strumenti di programmazione AI, architettura organizzativa e paradigmi dell’ingegneria del software — per esempio come cambia la legge di Conway nell’era degli agent AI nel 2026, la maturità del più recente ecosistema di strumenti, e altro ancora. Segui la serie per insight in continuo aggiornamento.

Sulla serie

“La trasformazione dell’ingegneria del software nell’era dell’AI” è una serie di ricerca approfondita per CIO, CDO, CTO e responsabili della digitalizzazione di settori come telecom, finanza, manifatturiero ed e-commerce — 15 pezzi in tutto. Costruita su oltre 200 paper accademici e report di settore, fornisce riferimenti decisionali annotati per livello di evidenza.

Sono un ex ingegnere IBM, coach certificato ICF, con esperienza sul campo nella consegna di progetti AI e digitali per operatori telefonici e grandi imprese. Quello che scrivo qui è il giudizio da campo maturato accompagnando le aziende dentro e fuori queste trappole.

Se hai finito di leggere e stai pensando “la nostra azienda è fatta così” — ho messo insieme un “Questionario di autovalutazione a 20 domande su Team Topologies”, e offro anche una chiamata diagnostica 1-a-1 di 30 minuti per aiutarti a localizzare quale flusso di valore riorganizzare per primo. Se ti serve: lascia un messaggio all’account ufficiale WeChat “AI Decision-Maker Insight”, oppure scrivi a coach@iaiuse.com.

Fonti

Skelton, M. & Pais, M. (2019). Team Topologies. IT Revolution Press. (fonte originaria dei quattro team / tre interazioni / carico cognitivo — fonte primaria)
Conway, M. (1968). How Do Committees Invent? Datamation.
Forsgren, Humble & Kim (2018). Accelerate. IT Revolution Press.
IT Revolution (2024). Team Topologies: Five Years of Transforming Organizations. (ricapitolazione di adozioni in più organizzazioni — fonte secondaria) https://itrevolution.com/articles/team-topologies-five-years-of-transforming-organizations/
Netflix Spinnaker / Spotify Backstage — casi di prodottizzazione della piattaforma interna
AutoTrader UK — caso di adozione citato da TT ufficiale (dettagli con link teamtopologies.com da completare)
Raccolta casi ufficiale: https://teamtopologies.com/examples