Le Team Topologies nella Pratica: Scegliere la Struttura del Team Giusta
"Team Topologies" di Skelton e Pais (2019) ha dato alla leadership d'ingegneria un vocabolario condiviso per la struttura dei team. Ma ho visto organizzazioni leggere il libro, rinominare tutti i loro team per adattarli ai quattro tipi, e non cambiare nulla su come fluisce davvero il lavoro. Altre creano team di piattaforma prima di avere qualcosa da platformizzare.
Ecco come applicarlo davvero nella pratica, incluso quando ristrutturare e quando lasciare le cose così come sono.
I Quattro Tipi di Team: Un Rapido Ripasso
Se hai letto il libro, passa alla sezione successiva. Se non l'hai fatto, ecco il modello centrale.
I team stream-aligned sono le unità primarie di consegna di valore. Possiedono un flusso di lavoro — un prodotto, un set di funzionalità, un dominio di business. Cross-funzionali e in grado di consegnare end-to-end. La maggior parte dei tuoi ingegneri dovrebbe essere qui.
I team enabling aiutano altri team ad adottare nuove tecnologie o capacità. Non costruiscono cose per altri team — aiutano altri team a costruire le cose da soli. Temporanei per design.
I team di piattaforma forniscono servizi interni che i team stream-aligned consumano come self-service. CI/CD, deploy, infrastruttura condivisa. Se i team devono aprire un ticket e aspettare, hai costruito un collo di bottiglia, non una piattaforma.
I team di sottosistema complesso possiedono componenti che richiedono conoscenza specialistica profonda — modelli ML, pipeline di dati in tempo reale, motori finanziari complessi. Creati quando il carico cognitivo è troppo alto per un team stream-aligned.
Quando Creare Ogni Tipo di Team
L'errore più comune è creare tutti e quattro i tipi contemporaneamente perché il libro descrive quattro tipi. In pratica, li introduci man mano che il bisogno emerge.
Stream-Aligned: Inizia Qui, Sempre
Ogni organizzazione d'ingegneria inizia con team stream-aligned, che li chiamino così o no. Se hai un team che costruisce un prodotto, quello è un team stream-aligned.
Man mano che cresci, la domanda diventa: come dividi? La risposta dovrebbe seguire i tuoi confini di dominio, non i tuoi strati tecnici. Dividi per user journey, dominio di business o area di prodotto — non per frontend/backend/infrastruttura.
Quando creare un nuovo team stream-aligned: Quando il carico cognitivo su un team esistente è troppo alto — possiedono troppi domini, il cambio di contesto è costante, e il team è sempre occupato ma consegna lentamente.
Piattaforma: Non Prima di Avere Domanda Reale
Qui è dove vedo più errori. La conversazione va: "Dovremmo avere un team di piattaforma." "Cosa costruirebbero?" "Sai... la piattaforma."
Un team di piattaforma ha senso quando:
- Più team stream-aligned stanno costruendo la stessa cosa indipendentemente. Tre team che costruiscono ciascuno la propria pipeline di deploy o configurazione di logging segnala che una capacità di piattaforma condivisa farebbe risparmiare tempo.
- I team stream-aligned stanno spendendo tempo significativo su lavoro non differenziante. Se i team prodotto spendono il 30% del loro tempo sulla manutenzione di infrastruttura o CI/CD, un team di piattaforma può assorbire quel carico.
- Il modello self-service è praticabile. Se la "piattaforma" richiede lavoro personalizzato per ogni consumatore, hai una coda di servizi condivisi, non una piattaforma.
Non creare un team di piattaforma quando: Hai meno di 4-5 team stream-aligned, o quando la "piattaforma" è davvero solo le esigenze infrastrutturali di un team travestite da iniziativa condivisa. Inizia con documentazione e librerie condivise. Se la domanda per una vera piattaforma cresce, lo saprai.
Enabling: Il Tipo Più Sottoutilizzato
La maggior parte delle organizzazioni non ha team enabling, e dovrebbe. Il team enabling è la risposta a una domanda che sento costantemente: "Come facciamo in modo che tutti i nostri team adottino X?"
X potrebbe essere:
- Osservabilità (log, metriche, tracce)
- Un nuovo framework di test
- Best practice di sicurezza
- Una migrazione da un database a un altro
- Standard di progettazione API
Senza un team enabling, l'adozione viene o mandata dall'alto verso il basso (creando risentimento) o non avviene affatto. Un team enabling lavora a fianco dei team stream-aligned come coach — pair programming, workshop, costruzione di strumenti che rendono l'adozione più facile.
Principio chiave: I team enabling dovrebbero avere un limite di tempo. Esistono per trasferire una capacità, non per possederla in modo permanente. Se il tuo sta "aiutando i team ad adottare l'osservabilità" da 18 mesi, qualcosa non va.
Sottosistema Complesso: Il Tipo Più Raro
Hai bisogno di un team di sottosistema complesso quando la conoscenza specialistica richiesta per un componente è così profonda che includerla in un team stream-aligned sovraccaricherebbe il carico cognitivo di quel team.
Esempi:
- Un motore di raccomandazione in tempo reale che richiede expertise ML
- Un modulo di elaborazione pagamenti con requisiti normativi complessi
- Una pipeline di transcodifica video che richiede conoscenza profonda di media engineering
- Un compilatore o un runtime di linguaggio
Il test è semplice: Un ingegnere generalista solido in un team stream-aligned potrebbe mantenere questo componente? Se sì, non hai bisogno di un team dedicato. Se la risposta è "solo se passa l'80% del suo tempo su di esso," quello è il tuo segnale.
La maggior parte delle startup e organizzazioni d'ingegneria di media scala ha zero o un team di sottosistema complesso. Se ne hai più di due, metti in discussione se stai over-specializzando.
I Tre Modi di Interazione
I modi di interazione sono la parte di Team Topologies che le persone saltano, e non dovrebbero. Come interagiscono i team è importante quanto come sono strutturati.
Modalità di collaborazione. Due team lavorano strettamente insieme per un periodo definito. Alto bandwidth, alto costo. Da usare per la scoperta e il lavoro in fase iniziale, non come stato permanente. Se due team collaborano permanentemente, dovrebbero unirsi.
Modalità X-as-a-Service. Un team fornisce una capacità attraverso un'interfaccia ben definita. La modalità principale tra i team di piattaforma e quelli stream-aligned. Funziona solo se è genuinamente self-service.
Modalità facilitante. Un team aiuta un altro a imparare o adottare una capacità. Come i team enabling interagiscono con i team stream-aligned. L'obiettivo è l'autosufficienza.
Quando Ristrutturare (e Quando No)
Le riorganizzazioni sono costose. Ogni riorg disturba le relazioni e costa settimane di produttività.
Ristruttura quando: I team non possono consegnare end-to-end senza bloccarsi a vicenda. Il perimetro di un team è così ampio che sono in costante cambio di contesto. Due team sono in modalità di collaborazione permanente (uniscili). Hai chiara domanda di piattaforma ma nessun team di piattaforma.
Non ristrutturare quando: Vuoi solo "provare Team Topologies." Il problema è nelle persone, non nella struttura. Il team funziona bene ma non si adatta alla tassonomia. Hai riorganizzato meno di 6 mesi fa.
Errori Comuni
Creare un team di piattaforma troppo presto. Costruire strumenti che nessuno usa mentre i team stream-aligned risolvono le proprie esigenze.
Non avere team enabling del tutto. Ogni iniziativa di adozione diventa un mandato dall'alto verso il basso o uno sforzo grassroots che si spegne.
Etichettare i team senza cambiare come lavorano. Rinominare "Team Backend" in "Team Piattaforma" non lo rende tale.
Ignorare il carico cognitivo. L'intero framework è costruito su di esso. Se non stai valutando se i team sono sovraccarichi, stai perdendo il punto.
In Conectia, quando integriamo ingegneri senior LATAM in organizzazioni d'ingegneria in crescita, prestiamo molta attenzione alla struttura del team. L'ingegnere giusto nel team sbagliato consegna meno valore di un buon ingegnere in un team ben strutturato. I nostri ingegneri hanno esperienza con configurazioni distribuite multi-team e capiscono come funzionano nella pratica le dinamiche di team stream-aligned, di piattaforma e enabling — non solo in teoria.
Stai strutturando i tuoi team d'ingegneria per la crescita? Parla con un CTO — posizioniamo ingegneri senior che capiscono le dinamiche dei team e si integrano perfettamente nella struttura del tuo squad dalla prima settimana.
