Team Topologies en la Práctica: Elegir la Estructura de Equipo Correcta
"Team Topologies" de Skelton y Pais (2019) le dio al liderazgo de ingeniería un vocabulario compartido para la estructura de equipos. Pero he visto organizaciones leer el libro, renombrar todos sus equipos para adaptarlos a los cuatro tipos y no cambiar nada sobre cómo fluye realmente el trabajo. Otras crean equipos de plataforma antes de tener algo que plataformizar.
Aquí está cómo aplicarlo realmente en la práctica, incluyendo cuándo reestructurar y cuándo dejar las cosas como están.
Los Cuatro Tipos de Equipos: Un Repaso Rápido
Si has leído el libro, salta a la siguiente sección. Si no, aquí está el modelo central.
Los equipos stream-aligned son las unidades primarias de entrega de valor. Poseen un flujo de trabajo — un producto, un conjunto de funcionalidades, un dominio de negocio. 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 otros equipos — ayudan a otros equipos a construir cosas ellos mismos. Temporales por diseño.
Los equipos de plataforma proporcionan servicios internos que los equipos stream-aligned consumen como autoservicio. CI/CD, despliegue, infraestructura compartida. Si los equipos necesitan abrir un ticket y esperar, has construido un cuello de botella, no una plataforma.
Los equipos de subsistema complicado poseen componentes que requieren conocimiento especialista profundo — modelos de ML, pipelines de datos en tiempo real, motores financieros complejos. Se crean cuando la carga cognitiva es demasiado alta para que un equipo stream-aligned la lleve.
Cuándo Crear Cada Tipo de Equipo
El error más común es crear los cuatro tipos a la vez porque el libro describe cuatro tipos. En la práctica, los introduces según surge la necesidad.
Stream-Aligned: Empieza Aquí, Siempre
Cada organización de ingeniería comienza con equipos stream-aligned, los llamen así o no. Si tienes un equipo construyendo un producto, ese es un equipo stream-aligned.
A medida que creces, la pregunta es: ¿cómo divides? La respuesta debería seguir los límites de tu dominio, no tus capas técnicas. Divide por viaje del 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 en un equipo existente es demasiado alta — poseen demasiados dominios, el cambio de contexto es constante y el equipo está ocupado todo el tiempo pero entregando lentamente.
Plataforma: No Hasta Tener Demanda Real
Aquí es donde veo más errores. La conversación va: "Deberíamos tener un equipo de plataforma." "¿Qué construirían?" "Ya sabes... la plataforma."
Un equipo de plataforma tiene sentido cuando:
- Múltiples equipos stream-aligned están construyendo la misma cosa de forma independiente. Tres equipos construyendo cada uno su propio pipeline de despliegue o configuración de logging señala que una capacidad de plataforma compartida ahorraría tiempo.
- Los equipos stream-aligned gastan tiempo significativo en trabajo no diferenciado. Si los equipos de producto gastan el 30% de su tiempo en mantenimiento de infraestructura o CI/CD, un equipo de plataforma puede absorber esa carga.
- El modelo de autoservicio es viable. Si la "plataforma" requiere trabajo personalizado 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" es realmente solo las necesidades de infraestructura de un equipo disfrazadas de iniciativa compartida. Empieza con documentación y bibliotecas compartidas. Si la demanda de una plataforma real crece, lo sabrá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 escucho constantemente: "¿Cómo conseguimos que todos nuestros equipos adopten X?"
X podría ser:
- Observabilidad (logs, métricas, trazas)
- Un nuevo framework de pruebas
- Mejores 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 se ordena de arriba hacia abajo (creando resentimiento) o no ocurre en absoluto. Un equipo enabling trabaja junto a los equipos stream-aligned como coaches — programación en pareja, talleres, construcción de herramientas que faciliten la adopción.
Principio clave: Los equipos enabling deberían tener tiempo limitado. Existen para transferir una capacidad, no para poseerla permanentemente. Si el tuyo lleva 18 meses "ayudando a los equipos a adoptar la observabilidad," algo está mal.
Subsistema Complicado: El Tipo Más Raro
Necesitas un equipo de subsistema complicado cuando el conocimiento especialista requerido para un componente es tan profundo que incluirlo en un equipo stream-aligned sobrecargarí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 video que requiere conocimiento profundo de ingeniería de medios
- Un compilador o runtime de lenguaje
La prueba es simple: ¿Podría un ingeniero generalista sólido en un equipo stream-aligned mantener este componente? Si es sí, no necesitas un equipo dedicado. Si la respuesta es "solo si gasta el 80% de su tiempo en ello," esa es tu señal.
La mayoría de las startups y organizaciones de ingeniería de escala media tienen cero o un equipo de subsistema complicado. Si tienes más de dos, cuestiona si estás sobre-especializando.
Los Tres Modos de Interacción
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 de colaboración. Dos equipos trabajan estrechamente juntos durante un período definido. Alto ancho de banda, alto costo. Úsalo para el descubrimiento y el trabajo en etapa inicial, no como un estado permanente. Si dos equipos colaboran permanentemente, deberían fusionarse.
Modo X-as-a-Service. Un equipo proporciona una capacidad a través de una interfaz bien definida. El modo principal entre los equipos de plataforma y los stream-aligned. Solo funciona si es genuinamente de autoservicio.
Modo de facilitación. Un equipo ayuda a otro a aprender o adoptar una capacidad. Cómo los equipos enabling interactúan con los equipos stream-aligned. El objetivo es la autosuficiencia.
Cuándo Reestructurar (y Cuándo No)
Las reorganizaciones son costosas. Cada reorg interrumpe las relaciones y cuesta semanas de productividad.
Reestructura cuando: Los equipos no pueden entregar de principio a fin sin bloquearse en otros. El alcance de un equipo es tan grande que están en constante cambio de contexto. Dos equipos están en modo de colaboración permanente (fusiónelos). Tienes demanda clara de plataforma pero no hay equipo de plataforma.
No reestructures cuando: Solo quieres "probar Team Topologies." El problema son las personas, no la estructura. El equipo funciona bien pero no encaja en la taxonomía. Reorganizaste hace menos de 6 meses.
Errores Comunes
Crear un equipo de plataforma demasiado pronto. Construir herramientas que nadie usa mientras los equipos stream-aligned resuelven sus propias necesidades.
No tener equipos enabling en absoluto. Cada iniciativa de adopción se convierte en un mandato de arriba hacia abajo o en un esfuerzo grassroots que se desvanece.
Etiquetar equipos sin cambiar cómo trabajan. Renombrar "Equipo Backend" a "Equipo de Plataforma" no lo convierte en uno.
Ignorar la carga cognitiva. Todo el framework está construido sobre ella. Si no estás evaluando si los equipos están sobrecargados, estás perdiendo el punto.
En Conectia, cuando incorporamos ingenieros senior de LATAM a organizaciones de ingeniería en crecimiento, prestamos mucha atención a la estructura del equipo. El ingeniero correcto en el equipo equivocado entrega menos valor que un buen ingeniero en un equipo bien estructurado. Nuestros ingenieros tienen experiencia con configuraciones distribuidas de múltiples equipos y entienden cómo funcionan en la práctica las dinámicas de equipos stream-aligned, de plataforma y enabling — no solo en teoría.
¿Estructurando tus equipos de ingeniería para el crecimiento? Habla con un CTO — colocamos ingenieros senior que entienden las dinámicas de equipo y se integran limpiamente en la estructura de tu squad desde la primera semana.
