Team Topologies a la pràctica: com triar l'estructura d'equips adequada
«Team Topologies» (2019), de Skelton i Pais, va donar als responsables d'enginyeria un vocabulari comú per parlar d'estructura d'equips. Però he vist organitzacions que es llegeixen el llibre, rebategen tots els equips perquè encaixin amb els quatre tipus i no canvien res de com circula realment la feina. D'altres creen equips de plataforma abans de tenir res a «plataformitzar».
Aquí explico com aplicar-lo de debò a la pràctica: quan toca reestructurar i quan val més deixar les coses com estan.
Els quatre tipus d'equip: un repàs ràpid
Si has llegit el llibre, salta directament a la secció següent. Si no, aquí en tens l'essencial.
Els equips alineats amb el flux són les unitats principals de lliurament de valor. Són responsables d'un flux de feina — un producte, un conjunt de funcionalitats, un domini de negoci. Multidisciplinaris i capaços de lliurar d'extrem a extrem. La majoria dels teus enginyers haurien de ser aquí.
Els equips habilitadors ajuden els altres equips a adoptar noves tecnologies o capacitats. No construeixen coses per als altres: els ajuden a construir-les ells mateixos. Temporals per disseny.
Els equips de plataforma ofereixen serveis interns que els equips alineats amb el flux consumeixen en autoservei. CI/CD, desplegaments, infraestructura compartida. Si els equips han d'obrir un tiquet i esperar-se, el que has construït és un coll d'ampolla, no una plataforma.
Els equips de subsistema complex s'encarreguen de components que demanen un coneixement especialitzat profund — models d'ML, pipelines de dades en temps real, motors financers complexos. Es creen quan la càrrega cognitiva és massa alta perquè la pugui assumir un equip alineat amb el flux.
Introdueix els tipus d'equip a mesura que calguin, no tots de cop
L'error més habitual és crear els quatre tipus alhora perquè el llibre en descriu quatre. A la pràctica, els introdueixes a mesura que en sorgeix la necessitat.
Alineat amb el flux: comença aquí, sempre
Totes les organitzacions d'enginyeria comencen amb equips alineats amb el flux, tant si en diuen així com si no. Si tens un equip que construeix un producte, allò és un equip alineat amb el flux.
A mesura que creixes, la pregunta passa a ser: com et divideixes? La resposta hauria de seguir els límits del domini, no les capes tècniques. Divideix per recorregut de l'usuari, per domini de negoci o per àrea de producte — no per frontend/backend/infraestructura.
Quan crear un nou equip alineat amb el flux: quan la càrrega cognitiva d'un equip existent és massa alta — gestiona massa dominis, canvia de context constantment i va de bòlit tot el dia però lliura poc.
Plataforma: no fins que hi hagi demanda real
Aquí és on veig més errors. La conversa sol anar així: «Hauríem de tenir un equip de plataforma.» «I què construirien?» «Home... la plataforma.»
Un equip de plataforma té sentit quan:
- Diversos equips alineats amb el flux estan construint el mateix pel seu compte. Que tres equips es muntin cadascun el seu pipeline de desplegament o el seu sistema de logs és senyal que una capacitat de plataforma compartida estalviaria temps.
- Els equips alineats amb el flux dediquen una part important del temps a feina no diferenciada. Si els equips de producte es passen el 30% del temps mantenint infraestructura o CI/CD, un equip de plataforma pot absorbir aquesta càrrega.
- El model d'autoservei és viable. Si la «plataforma» requereix feina a mida per a cada consumidor, el que tens és una cua de serveis compartits, no una plataforma.
No creïs un equip de plataforma quan: tens menys de 4-5 equips alineats amb el flux, o quan la «plataforma» són en realitat les necessitats d'infraestructura d'un sol equip disfressades d'iniciativa compartida. Comença amb documentació i biblioteques compartides. Si la demanda d'una plataforma de debò creix, ja te n'adonaràs.
Habilitador: el tipus més infrautilitzat
La majoria d'organitzacions no tenen equips habilitadors, i n'haurien de tenir. L'equip habilitador és la resposta a una pregunta que sento constantment: «Com aconseguim que tots els equips adoptin X?»
X pot ser:
- Observabilitat (logs, mètriques, traces)
- Un framework de proves nou
- Bones pràctiques de seguretat
- Una migració d'una base de dades a una altra
- Estàndards de disseny d'API
Sense un equip habilitador, l'adopció o bé s'imposa des de dalt (i genera ressentiment) o bé directament no passa. Un equip habilitador treballa colze a colze amb els equips alineats amb el flux, fent de mentor: pair programming, tallers, eines que facilitin l'adopció.
Principi clau: els equips habilitadors han de tenir data de caducitat. Existeixen per transferir una capacitat, no per quedar-se-la per sempre. Si el teu fa 18 mesos que «ajuda els equips a adoptar l'observabilitat», alguna cosa falla.
Subsistema complex: el tipus més rar
Necessites un equip de subsistema complex quan el coneixement especialitzat que demana un component és tan profund que encabir-lo en un equip alineat amb el flux dispararia la càrrega cognitiva d'aquell equip.
Exemples:
- Un motor de recomanacions en temps real que requereix expertesa en ML
- Un mòdul de processament de pagaments amb requisits regulatoris complexos
- Un pipeline de transcodificació de vídeo que demana coneixement profund d'enginyeria de mèdia
- Un compilador o el runtime d'un llenguatge
La prova és senzilla: un bon enginyer generalista d'un equip alineat amb el flux, podria mantenir aquest component? Si la resposta és que sí, no et cal un equip dedicat. Si la resposta és «només si hi dedica el 80% del temps», aquest és el senyal.
La majoria de startups i organitzacions d'enginyeria de mida mitjana tenen zero o un equip de subsistema complex. Si en tens més de dos, pregunta't si no estàs sobreespecialitzant.
Els modes d'interacció importen tant com l'estructura
Els modes d'interacció són la part de Team Topologies que la gent se salta, i no se l'hauria de saltar. Com interactuen els equips importa tant com la manera com estan estructurats.
Mode de col·laboració. Dos equips treballen estretament junts durant un període definit. Molta amplada de banda, molt de cost. Fes-lo servir per al descobriment i les fases inicials, no com a estat permanent. Si dos equips col·laboren permanentment, s'haurien de fusionar.
Mode X-as-a-Service. Un equip ofereix una capacitat a través d'una interfície ben definida. És el mode principal entre equips de plataforma i equips alineats amb el flux. Només funciona si és autoservei de debò.
Mode de facilitació. Un equip ajuda un altre a aprendre o adoptar una capacitat. És com els equips habilitadors interactuen amb els alineats amb el flux. L'objectiu és l'autosuficiència.
Quan reestructurar (i quan no)
Les reorganitzacions surten cares. Cada reorganització trenca relacions i costa setmanes de productivitat.
Jo reestructuraria quan:
- Els equips no poden lliurar d'extrem a extrem sense quedar bloquejats pels altres.
- L'abast d'un equip és tan gran que viu canviant de context.
- Dos equips estan en mode de col·laboració permanent (fusiona'ls).
- Tens una demanda clara de plataforma però cap equip de plataforma.
I no ho faria quan:
- Només vols «provar Team Topologies».
- El problema és la gent, no l'estructura.
- L'equip funciona bé però no encaixa en la taxonomia.
- Vas reorganitzar fa menys de 6 mesos.
Els errors que veig una vegada i una altra
Crear un equip de plataforma massa d'hora. Construir eines que ningú fa servir mentre els equips alineats amb el flux es resolen les necessitats pel seu compte.
No tenir cap equip habilitador. Cada iniciativa d'adopció acaba sent un mandat de dalt a baix o un esforç de base que es desinfla.
Etiquetar els equips sense canviar com treballen. Rebatejar l'«equip de backend» com a «equip de plataforma» no el converteix en un equip de plataforma.
Ignorar la càrrega cognitiva. Tot el marc s'hi fonamenta. Si no avalues si els equips van sobrecarregats, se t'escapa l'essencial.
A Conectia, quan integrem enginyers sèniors de LATAM en organitzacions d'enginyeria que creixen, ens fixem molt en l'estructura dels equips. L'enginyer adequat a l'equip equivocat aporta menys valor que un bon enginyer en un equip ben estructurat. Els nostres enginyers tenen experiència en entorns distribuïts amb múltiples equips i saben com funcionen a la pràctica — no només en teoria — les dinàmiques entre equips alineats amb el flux, de plataforma i habilitadors.
Estàs estructurant els teus equips d'enginyeria per créixer? Parla amb un CTO — col·loquem enginyers sèniors que entenen les dinàmiques d'equip i s'integren a l'estructura dels teus squads sense friccions des de la primera setmana.
