Team Topologies per chi guida un'azienda software

Quando un'azienda software cresce, la prima reazione è assumere. Più persone, più velocità: sembra logico. Eppure, oltre una certa soglia, aggiungere sviluppatori non solo non accelera la delivery; la rallenta. Le stime peggiorano, i rilasci si complicano, i team passano più tempo a coordinarsi che a scrivere codice.

Il problema non è nelle persone. È nella struttura. E Team Topologies, il modello di Matthew Skelton e Manuel Pais, offre un linguaggio concreto per affrontarlo.

Questo articolo traduce quei principi in decisioni operative per chi guida un'azienda: non in teoria organizzativa, ma in scelte che impattano direttamente la velocità del software.

Perché la struttura dei team determina la velocità del software

La legge di Conway, formulata nel 1967 e confermata da decenni di pratica, dice che la struttura del software riflette la struttura dell'organizzazione che lo produce. Non è un suggerimento; è un vincolo fisico.

Se i team sono organizzati per tecnologia (un team frontend, un team backend, un team infrastruttura), il software avrà tre strati accoppiati. Ogni funzionalità richiederà il coordinamento di tutti e tre. Ogni rilascio diventerà un progetto multi-team.

Se i team sono organizzati per dominio di business (un team pagamenti, un team catalogo, un team logistica), il software tenderà naturalmente verso moduli indipendenti. Ogni team potrà rilasciare in autonomia, perché possiede l'intero flusso dalla interfaccia utente ai dati.

La struttura organizzativa non è un dettaglio amministrativo: è una decisione architetturale.

I quattro tipi di team

Team Topologies definisce quattro tipi fondamentali di team, ciascuno con uno scopo preciso:

• Team stream-aligned: sono i team di delivery principali. Ciascuno è responsabile di un flusso di valore per il business (un prodotto, una funzionalità, un segmento di clienti). Possiedono tutto ciò che serve per rilasciare: codice, test, deployment, monitoraggio. La maggior parte dei team in un'organizzazione dovrebbe essere di questo tipo
• Team platform: costruiscono e mantengono le piattaforme interne che rendono autonomi i team stream-aligned. Pipeline CI/CD, infrastruttura, strumenti di monitoring. Il loro prodotto è l'esperienza di sviluppo degli altri team
• Team enabling: affiancano temporaneamente i team stream-aligned per trasferire competenze specifiche. Non fanno il lavoro al posto degli altri; li rendono capaci. Sono temporanei per design: quando il team ha acquisito la competenza, l'enabling team si ritira
• Team complicated-subsystem: gestiscono parti del sistema che richiedono competenze specialistiche profonde (motori di calcolo, algoritmi complessi, componenti di sicurezza). Esistono perché il carico cognitivo di quel sottosistema supererebbe la capacità di un team generalista

La regola fondamentale: ogni team deve sapere con chiarezza di che tipo è. Se non lo sa, sta probabilmente facendo un po' di tutto, ed è parte del problema.

Il carico cognitivo: il limite invisibile

Ogni team ha una capacità cognitiva limitata. È la quantità di conoscenza che può gestire contemporaneamente: la codebase, gli strumenti, i processi, i domini di business. Quando questa capacità viene superata, la produttività crolla, gli errori aumentano e l'onboarding di nuove persone diventa lentissimo.

Tre tipi di carico cognitivo pesano sui team:

• Carico intrinseco: la complessità del dominio di business stesso. È inevitabile e va accettato
• Carico estraneo: complessità che il team subisce ma che non dovrebbe gestire. Strumenti mal configurati, processi burocratici, infrastruttura da manutenere manualmente. Questo carico va eliminato: è il lavoro dei team platform
• Carico pertinente: la complessità delle scelte tecniche che il team deve fare per risolvere i problemi del business. Questo carico va gestito con competenza

Ridurre il carico cognitivo è più efficace che aggiungere persone. Un team con carico gestibile consegna più velocemente di un team doppio con carico eccessivo. È la ragione per cui aggiungere sviluppatori spesso non migliora la velocità: se il carico cognitivo resta lo stesso, più persone significano solo più coordinamento.

Le tre modalità di interazione

Team Topologies non definisce solo i tipi di team: definisce anche come devono interagire. Tre modalità, ciascuna con uno scopo preciso:

• Collaborazione: due team lavorano insieme, fianco a fianco, per un periodo limitato. Serve quando si esplora un nuovo dominio o si costruisce qualcosa che nessuno dei due team potrebbe fare da solo. È temporanea: se dura più di qualche settimana, qualcosa non funziona
• X-as-a-Service: un team fornisce un servizio all'altro con interfacce chiare e documentate. Il team che consuma il servizio non ha bisogno di sapere come funziona internamente. È il modello target per la maggior parte delle interazioni
• Facilitazione: un team enabling affianca un team stream-aligned per trasferire competenze. Non fa il lavoro; insegna a farlo. La facilitazione ha una scadenza: quando il team è autonomo, l'interazione si chiude

Se due team hanno bisogno di coordinarsi costantemente senza rientrare in nessuna di queste modalità, è un segnale: i confini tra i team (e tra i moduli software che possiedono) sono nel posto sbagliato.

Come applicare questi principi in una PMI

Team Topologies nasce dall'esperienza con organizzazioni grandi, ma i principi si applicano anche con 3-4 team. La scala cambia; i vincoli restano gli stessi.

Con il servizio di Innesto, entriamo spesso come team aggiuntivo in organizzazioni che non hanno ancora applicato nessun framework di design organizzativo. Quello che vediamo quasi sempre è la variante più diffusa del problema: team organizzati per tecnologia — frontend, backend, mobile, data — invece che per dominio di business. Ogni feature richiede coordinamento tra tutti i team. Il passaggio a team per dominio sembra semplice sulla carta. Nella pratica richiede 6-12 mesi, non per le difficoltà tecniche, ma perché significa ridisegnare ownership, responsabilità e interfacce tra team — e farlo mentre il prodotto continua a essere sviluppato.

In una PMI con 15-30 sviluppatori, le azioni concrete sono:

1. Organizzare i team per dominio di business, non per tecnologia: il team "pagamenti" possiede tutto il flusso (frontend, backend, dati); non esiste un "team frontend" separato. Ogni team può rilasciare in autonomia
2. Definire un team platform minimo: anche solo una persona dedicata a mantenere la pipeline CI/CD, il monitoring e gli strumenti di sviluppo. L'obiettivo è che i team stream-aligned non debbano preoccuparsi dell'infrastruttura
3. Misurare il carico cognitivo: se un team gestisce più di 2-3 componenti indipendenti, il carico è probabilmente eccessivo. Ridurlo, anche redistribuendo le responsabilità, è più efficace che assumere
4. Rendere esplicite le modalità di interazione: ogni coppia di team deve sapere se sta collaborando, consumando un servizio, o in fase di facilitazione. L'ambiguità genera coordinamento implicito, che è il tipo più costoso

Se la struttura attuale dei team non rispecchia questi principi, la ristrutturazione non deve essere un big-bang. Si inizia da un team, si verifica che funziona, e si espande. È lo stesso approccio incrementale che applichiamo con il servizio di innesto nell'organizzazione.

Cosa fare concretamente

Tre azioni da fare questa settimana:

1. Disegnare la mappa attuale: quali team esistono, cosa possiedono, come interagiscono. Mettere tutto su una lavagna. Se il disegno è confuso, anche l'organizzazione lo è
2. Identificare il team con più dipendenze: è quello che si blocca più spesso aspettando altri team. Le dipendenze tra team sono il sintomo più visibile di una struttura disallineata
3. Ridurre il carico di un team: scegliere un team e togliergli una responsabilità che non dovrebbe avere. Un componente che potrebbe appartenere a un altro team, uno strumento che potrebbe gestire il team platform. Un solo spostamento, per vedere l'effetto

La struttura dei team non è un organigramma da aggiornare una volta all'anno. È una decisione architetturale che va rivista ogni volta che il prodotto, il mercato o l'organizzazione cambiano. Chi la progetta con intenzione accelera; chi la subisce rallenta.