Team Topologies en la práctica: cómo elegir la estructura de equipo adecuada
«Team Topologies», de Skelton y Pais (2019), dio al liderazgo de ingeniería un vocabulario común para hablar de estructura de equipos. Pero he visto organizaciones que leen el libro, renombran todos sus equipos para encajarlos en los cuatro tipos y no cambian nada de cómo fluye el trabajo en realidad. Otras crean equipos de plataforma antes de tener nada que convertir en plataforma.
Esto es lo que de verdad funciona al aplicarlo en la práctica, incluyendo cuándo reestructurar y cuándo dejar las cosas como están.
Los cuatro tipos de equipo: un repaso rápido
Si ya has leído el libro, salta a la siguiente sección. Si no, este es el modelo en esencia.
Los equipos stream-aligned son las unidades primarias de entrega de valor. Cada uno es dueño de un flujo de trabajo — un producto, un conjunto de funcionalidades, un dominio de negocio. Son multifuncionales y capaces de entregar de principio a fin. La mayoría de tus ingenieros deberían estar aquí.
Los equipos enabling ayudan a otros equipos a adoptar nuevas tecnologías o capacidades. No construyen cosas para los demás: les ayudan a construirlas por sí mismos. Son temporales por diseño.
Los equipos de plataforma ofrecen servicios internos que los equipos stream-aligned consumen en autoservicio. CI/CD, despliegue, infraestructura compartida. Si los equipos tienen que abrir un ticket y esperar, has construido un cuello de botella, no una plataforma.
Los equipos de subsistema complicado son dueños de componentes que exigen conocimiento especializado muy profundo — modelos de ML, pipelines de datos en tiempo real, motores financieros complejos. Se crean cuando la carga cognitiva es demasiado alta para que la asuma un equipo stream-aligned.
Introduce los tipos de equipo según los necesites, no todos a la vez
El error más común es crear los cuatro tipos de golpe porque el libro describe cuatro tipos. En la práctica, se introducen a medida que surge la necesidad.
Stream-aligned: empieza aquí, siempre
Toda organización de ingeniería empieza con equipos stream-aligned, los llame así o no. Si tienes un equipo construyendo un producto, eso es un equipo stream-aligned.
A medida que creces, la pregunta pasa a ser: ¿por dónde divides? La respuesta debería seguir las fronteras de tu dominio, no tus capas técnicas. Divide por recorrido de usuario, dominio de negocio o área de producto — no por frontend/backend/infraestructura.
Cuándo crear un nuevo equipo stream-aligned: cuando la carga cognitiva de un equipo existente es demasiado alta — son dueños de demasiados dominios, el cambio de contexto es constante y el equipo está siempre ocupado pero entrega despacio.
Plataforma: no hasta que haya demanda real
Aquí es donde veo más errores. La conversación suele ser: «Deberíamos tener un equipo de plataforma.» «¿Y qué construirían?» «Ya sabes... la plataforma.»
Un equipo de plataforma tiene sentido cuando:
- Varios equipos stream-aligned están construyendo lo mismo por separado. Tres equipos montando cada uno su propio pipeline de despliegue o su propio logging es la señal de que una capacidad de plataforma compartida ahorraría tiempo.
- Los equipos stream-aligned dedican una parte significativa de su tiempo a trabajo no diferenciado. Si los equipos de producto invierten el 30% de su tiempo en mantener infraestructura o CI/CD, un equipo de plataforma puede absorber esa carga.
- El modelo de autoservicio es viable. Si la «plataforma» requiere trabajo a medida para cada consumidor, tienes una cola de servicios compartidos, no una plataforma.
No crees un equipo de plataforma cuando: tienes menos de 4-5 equipos stream-aligned, o cuando la «plataforma» no es más que las necesidades de infraestructura de un equipo disfrazadas de iniciativa compartida. Empieza con documentación y librerías compartidas. Si la demanda de una plataforma de verdad crece, lo notarás.
Enabling: el tipo más infrautilizado
La mayoría de las organizaciones no tienen equipos enabling, y deberían. El equipo enabling es la respuesta a una pregunta que oigo constantemente: «¿Cómo conseguimos que todos nuestros equipos adopten X?»
X puede ser:
- Observabilidad (logs, métricas, trazas)
- Un nuevo framework de testing
- Buenas prácticas de seguridad
- Una migración de una base de datos a otra
- Estándares de diseño de API
Sin un equipo enabling, la adopción o se impone desde arriba (generando resentimiento) o directamente no ocurre. Un equipo enabling trabaja codo con codo con los equipos stream-aligned, como entrenadores: programación en pareja, talleres, herramientas que hacen la adopción más fácil.
Principio clave: los equipos enabling deben estar acotados en el tiempo. Existen para transferir una capacidad, no para quedársela en propiedad. Si el tuyo lleva 18 meses «ayudando a los equipos a adoptar observabilidad», algo va mal.
Subsistema complicado: el tipo más infrecuente
Necesitas un equipo de subsistema complicado cuando el conocimiento especializado que exige un componente es tan profundo que incrustarlo en un equipo stream-aligned desbordaría la carga cognitiva de ese equipo.
Ejemplos:
- Un motor de recomendaciones en tiempo real que requiere experiencia en ML
- Un módulo de procesamiento de pagos con requisitos regulatorios complejos
- Un pipeline de transcodificación de vídeo que exige conocimiento profundo de ingeniería de medios
- Un compilador o el runtime de un lenguaje
La prueba es sencilla: ¿podría un buen ingeniero generalista de un equipo stream-aligned mantener este componente? Si la respuesta es sí, no necesitas un equipo dedicado. Si la respuesta es «solo si le dedica el 80% de su tiempo», esa es tu señal.
La mayoría de las startups y organizaciones de ingeniería de tamaño medio tienen cero o un equipo de subsistema complicado. Si tienes más de dos, plantéate si te estás sobreespecializando.
Los modos de interacción importan tanto como la estructura
Los modos de interacción son la parte de Team Topologies que la gente se salta, y no debería. Cómo interactúan los equipos importa tanto como cómo están estructurados.
Modo colaboración. Dos equipos trabajan estrechamente durante un periodo definido. Mucho ancho de banda, mucho coste. Úsalo para descubrimiento y fases tempranas, no como estado permanente. Si dos equipos colaboran de forma permanente, deberían fusionarse.
Modo X-as-a-Service. Un equipo ofrece una capacidad a través de una interfaz bien definida. Es el modo principal entre equipos de plataforma y equipos stream-aligned. Solo funciona si es autoservicio de verdad.
Modo facilitación. Un equipo ayuda a otro a aprender o adoptar una capacidad. Es como los equipos enabling interactúan con los stream-aligned. El objetivo es la autosuficiencia.
Cuándo reestructurar (y cuándo no)
Las reorganizaciones salen caras. Cada reorganización rompe relaciones y cuesta semanas de productividad.
Yo reestructuraría cuando:
- Los equipos no pueden entregar de principio a fin sin quedarse bloqueados por otros.
- El alcance de un equipo es tan grande que vive en cambio de contexto permanente.
- Dos equipos están en modo colaboración permanente (fusiónalos).
- Hay demanda clara de plataforma pero no hay equipo de plataforma.
No lo haría cuando:
- Solo quieres «probar Team Topologies».
- El problema son las personas, no la estructura.
- El equipo funciona bien aunque no encaje en la taxonomía.
- Reorganizaste hace menos de 6 meses.
Los errores que veo una y otra vez
Crear un equipo de plataforma demasiado pronto. Construye herramientas que nadie usa mientras los equipos stream-aligned resuelven sus necesidades por su cuenta.
No tener ningún equipo enabling. Cada iniciativa de adopción acaba siendo un mandato desde arriba o un esfuerzo de base que se apaga solo.
Etiquetar equipos sin cambiar cómo trabajan. Renombrar el «equipo de backend» como «equipo de plataforma» no lo convierte en uno.
Ignorar la carga cognitiva. Todo el framework se sostiene sobre ella. Si no estás evaluando si tus equipos están sobrecargados, te estás perdiendo lo esencial.
En Conectia, cuando integramos ingenieros senior de LATAM en organizaciones de ingeniería en crecimiento, prestamos mucha atención a la estructura de equipos. El ingeniero adecuado en el equipo equivocado aporta menos valor que un buen ingeniero en un equipo bien estructurado. Nuestros ingenieros tienen experiencia en entornos distribuidos con múltiples equipos y entienden cómo funcionan en la práctica — no solo en la teoría — las dinámicas entre equipos stream-aligned, de plataforma y enabling.
¿Estás estructurando tus equipos de ingeniería para crecer? Habla con un CTO — incorporamos ingenieros senior que entienden las dinámicas de equipo y se integran con naturalidad en tu estructura de squads desde la primera semana.
