¿Te acuerdas del famoso modelo Spotify? Ése que todo el mundo ponía en sus presentaciones como si fueran cromos. No voy a decir que fuera un mal ejemplo: sirvió para que muchas empresas empezaran a pensar en equipos multidisciplinares y autónomos. El problema vino cuando se convirtió en un póster decorativo: se repetía la forma, pero se descuidaba el fondo.
Ahí es donde aparece Team Topologies. Hace un par de años ya publiqué una presentación introductoria sobre el libro, pero hoy quiero explicarte por qué los patrones de este enfoque son tan relevantes, qué problemas intentan resolver y cómo pueden realmente transformar la agilidad empresarial.
Team Topologies en pocas palabras
Este enfoque fue creado por Matthew Skelton y Manuel Pais y publicado en 2019 en el libro Team Topologies. Nació como respuesta a los problemas de escalabilidad y complejidad organizativa que muchas empresas de software sufrían, cuando modelos de referencia como el de Spotify se mostraban ineficaces para organizar equipos de forma efectiva. Su propósito es aportar un conjunto de patrones claros para abordar estos retos. De hecho, originalmente aparecen con el nombre de DevOps Topologies.
No es un framework ni una receta cerrada. Es, más bien, una forma práctica de pensar cómo organizamos nuestros equipos y cómo estos interactúan entre sí. Porque, al final, la agilidad empresarial depende de cómo fluye el valor a través de tu organización. Por cierto, quédate con este concepto —el flujo de valor— porque lo vamos a repetir hasta la saciedad.
Team Topologies propone una serie de patrones que ayudan a diseñar esas estructuras e interacciones de forma intencionada, y son los que veremos a continuación.
¿Por qué necesitamos estos patrones?
La premisa central de Team Topologies es que la forma en que organizas equipos y cómo interactúan afecta directamente a la arquitectura del producto, la velocidad de entrega y la capacidad de adaptarse al cambio. Esta idea conecta directamente con la Ley de Conway, que sostiene que “Las organizaciones están condenadas a producir sistemas que son copia de sus estructuras de comunicación”.
Si tus equipos se comunican de forma lenta, debido a silos de conocimiento y multitud de dependencias entre equipos, tus sistemas también lo reflejarán. Y al revés: si quieres una arquitectura más modular y flexible, necesitas rediseñar tus equipos para que trabajen así. A esto se le llama la maniobra inversa de Conway.
Por eso, si no definimos intencionadamente cómo se organizan los equipos (y cómo se comunican), la estructura del sistema —y el flujo de valor que la atraviesa— tenderá a reflejar las ineficiencias organizativas. Para una explicación más amplia, puedes ver mi artículo:
Aquí entra en juego otro concepto clave: la carga cognitiva. Cada equipo tiene una capacidad limitada para comprender y gestionar la complejidad de su dominio. Team Topologies toma este concepto de la teoría del aprendizaje para recordarnos que, cuando esa capacidad se desborda —porque el equipo asume demasiadas responsabilidades, dependencias o tecnologías—, la colaboración se degrada y el valor deja de fluir. Por eso, el diseño organizativo debe cuidar tanto la arquitectura del producto como la capacidad mental colectiva necesaria para sostenerla.
Los patrones de Team Topologies ayudan precisamente a equilibrar esas dos tensiones: diseñar equipos y relaciones que reflejen una arquitectura sana y que mantengan la carga cognitiva dentro de límites sostenibles.
Las 4 topologías fundamentales
Team Topologies propone cuatro tipos de equipo con roles bien diferenciados:
- Equipo orientado al flujo: Alineado con un único flujo de valor. Su trabajo se centra en un único producto o servicio, un único conjunto de funcionalidades, un único user journey o una única user persona.
El propósito del resto de topologías será reducir la carga de estos equipos alineados al flujo de cambios.
- Equipo habilitador: Ayuda a los equipos alineados al flujo a superar obstáculos y detecta capacidades faltantes. Tiene holgura para investigar, probar opciones y hacer sugerencias informadas.
- Equipo de subsistema complicado: Responsable de construir y mantener una parte del sistema que depende altamente de conocimiento muy especializado (difícilmente estandarizable o adquirido mediante una formación).
- Equipo de plataforma: Agrupación de otros tipos de equipos que proporcionan servicios internos que reducen la carga cognitiva de los equipos orientados al flujo.
Los 3 modos básicos de interacción
Sólo hay 3 modos en los que los equipos deberían interaccionar:
- Colaboración: Trabajar juntos por un período de tiempo (no indefinidamente) para explorar algo nuevo (APIs, prácticas, tecnologías, etc). → Descubrimiento rápido
- X-as-a-Service: un equipo proporciona y un equipo consume algo “como un servicio”, e.d. la solicitud está estandarizada y el resultado es predecible. → Entrega predecible
- Facilitación: Un equipo ayuda o mentoriza a otro equipo para que adquiera nuevas capacidades. → Ayuda activa
Con esta simplificación radical se consigue lo que muchas organizaciones llevan años buscando: reducir fricciones, acortar tiempos y que cada equipo sepa para qué existe, cómo se debe relacionar con los demás y cómo los demás se deben relacionar con él.
La imagen a continuación es un resumen de estos patrones con la notación empleada originalmente.
En los ejemplos que verás a continuación empleo otra notación más actual para los modos de interacción, pero el significado es el mismo.
Un ejemplo de estos patrones en acción
Imagina que una aerolínea organiza su desarrollo en torno a una aplicación móvil de reservas y gestión de vuelos, usando el modelo Team Topologies para estructurar sus equipos. Los equipos orientados al flujo de valor se encargan de entregar funcionalidades directamente a los clientes: el equipo de Reservas Online mejora continuamente la experiencia de búsqueda, compra y check-in, mientras que el equipo de Fidelización gestiona el programa de puntos y beneficios. Ambos colaboran para integrar sus servicios y ofrecer una experiencia fluida al usuario final.
El equipo habilitador de UX Research actúa de forma temporal para ayudar a los equipos de producto a adoptar prácticas avanzadas de diseño centrado en el usuario. Este acompañamiento (facilitación) se limita al tiempo necesario para que los equipos integren los nuevos aprendizajes y trabajen de forma más autónoma.
En paralelo, el equipo de subsistema complicado desarrolla el Motor de Precios, un motor de tarifas y disponibilidad que expone su funcionalidad como servicio a los equipos de producto. La plataforma digital (DXP) proporciona servicios comunes —autenticación, despliegue, observabilidad— usados por todos los equipos (X-as-a-Service), asegurando coherencia técnica y facilitando un flujo de entrega más rápido. Así, la organización combina colaboración, especialización y autonomía para sostener su agilidad a gran escala.
El resultado final: el equipo de flujo puede centrarse en entregar valor al cliente sin ahogarse en dependencias ni problemas técnicos que otros tipos de equipo resuelven mejor.
NOTA: Para crear tus propios diagramas, puedes usar Miro e instalar la herramienta “Team Topologies” pulsando en el botón para Añadir Herramientas (en el menú de la izquierda).
Por cierto, si tienes interés en aprender más sobre Team Topologies, creo que este recurso te resultará muy útil. Se trata de una plantilla Miro para un organizar un club de lectura enfocado en el libro: https://miro.com/templates/team-topologies-book-club-guide-template/
Qué cambia realmente al aplicar Team Topologies
Aplicar Team Topologies no consiste en subirse a otra moda, sino en intervenir en las entrañas del sistema para que la agilidad ocurra de verdad. No añade capas de reglas (como hacen la mayoria de marcos de trabajo), sino que reconstruye las condiciones que hacen posible que la agilidad emerja.
Siguiendo las categorías de potenciadores e inhibidores que propone Sunil Mundra:
- En la estructura organizativa, los equipos dejan de alinearse por departamentos para hacerlo alrededor de flujos de valor. Los equipos orientados al flujo sustituyen a los silos funcionales y reducen dependencias, mientras que el resto de equipos limitan la carga cognitiva y permiten que la organización se adapte sin fricción. La estructura ya no es un obstáculo: se convierte en un instrumento de aprendizaje.
- En los procesos, Team Topologies pone orden donde antes había improvisación o burocracia. Define interacciones claras entre equipos —colaborar, facilitar, proveer servicios— y convierte el trabajo en flujo continuo. El foco deja de estar en los proyectos y pasa a estar en los outcomes: entregas pequeñas, feedback rápido y aprendizaje constante.
- El cambio también se nota en las personas. La autonomía deja de ser un discurso y se vuelve tangible cuando los equipos tienen límites claros y responsabilidad de extremo a extremo. Los equipos habilitadores ayudan a otros a adquirir nuevas capacidades, reduciendo la sobrecarga y fomentando la colaboración. Con menos ruido y más claridad, la motivación deja de depender del carisma de los líderes y pasa a surgir del propio trabajo bien diseñado.
- La tecnología deja de ser un cuello de botella y se convierte en un aliado. La maniobra inversa de Conway —diseñar equipos para inducir la arquitectura deseada— permite que los sistemas evolucionen al ritmo del negocio. Las plataformas, tratadas como productos, eliminan fricciones y devuelven velocidad a los equipos de flujo.
- En cuanto a gobernanza, Team Topologies cambia el control por la confianza. Las decisiones se toman donde está el conocimiento, y la visibilidad del flujo sustituye los comités interminables. La gestión de proyectos se convierte en gobernanza por flujos: más trazabilidad del valor, menos supervisión innecesaria.
- Y, finalmente, cambia la relación con el cliente. Al tener equipos alineados con los flujos de valor, el feedback llega antes, la empatía se amplifica y la experimentación se vuelve natural. Los equipos entienden el impacto de su trabajo en la experiencia real del usuario y pueden ajustar el rumbo sin esperar a una gran revisión trimestral (como en el caso de SAFe).
Para un CxO o un responsable de transformación, la pregunta no es si aplicar Team Topologies o no, sino cuánto tardarás en darte cuenta de que la capacidad competitiva de tu organización depende de rediseñar los equipos en torno al flujo de valor.
Qué aporta la segunda edición
Acaba de salir publicada la segunda edición y no quería perder la oportunidad de mencionar qué hay de nuevo en la misma. No es una revisión menor: amplía el marco con matices que reflejan lo aprendido tras años de aplicación en organizaciones de todo tipo.
La principal novedad es la aclaración sobre el concepto de plataforma. Los autores precisan (también aquí) que un equipo de plataforma no siempre es un único equipo, sino que puede tratarse de un agrupamiento de equipos (platform grouping) que, en conjunto, ofrece los servicios necesarios a los equipos de flujo. Esta ampliación da lugar a la idea de value stream grouping y subraya lo que ellos llaman la naturaleza fractal de las organizaciones: patrones que se repiten a distintos niveles de escala, desde un equipo hasta un ecosistema completo de plataformas.
La segunda aportación importante es un anexo de casos reales, que documenta experiencias concretas de aplicación de Team Topologies en empresas y administraciones públicas. Más que ejemplos de éxito, son referencias bastante valiosas para entender cómo se adapta el modelo sin perder su esencia.
Y finalmente también tenemos un epílogo en el que los autores miran hacia el futuro con optimismo. Así, celebran que sus ideas hayan ayudado a construir organizaciones más humanas y efectivas, y destacan la conexión con otros marcos complementarios como Wardley Mapping o Domain-Driven Design. Además, la carga cognitiva ocupa ahora un lugar aún más central: cuando los equipos trabajan dentro de límites saludables, esto permite que la calidad, la innovación y la simplicidad florezcan. Frente a la tentación de automatizarlo todo, los autores insisten en usar la tecnología (las IAs) para ampliar las capacidades humanas, no para sustituirlas.
Si quieres ver cómo estas ideas se están materializando en organizaciones reales, puedes echar un vistazo a la charla Emerging Patterns & Anti-Patterns with Team Topologies, donde los propios autores comparten aprendizajes recientes y los retos que están emergiendo al escalar el modelo.
Repensar la agilidad desde la estructura
A veces confundimos la agilidad con moverse rápido, cuando en realidad se trata de moverse con sentido. Team Topologies nos recuerda que la agilidad no nace de los rituales ni de las etiquetas, sino de una estructura que permite a las personas concentrarse en lo que importa.
Cada vez que un equipo se ve atrapado en dependencias, en burocracia o en métricas vacías, el sistema nos está diciendo algo: que la organización necesita rediseñarse para liberar su propio potencial. No hay transformación posible si la estructura sigue jugando en contra. En ese sentido, Team Topologies no es sólo un modelo de organización de equipos, sino una invitación a mirar la agilidad desde sus cimientos y a preguntarnos no “qué framework necesitamos”, sino “qué impedimentos estamos diseñando”.
FOTO: Como sabes, me gustan mucho emplear metáforas para entender mejor los conceptos. Esta foto de Acton Crawford en Unsplash sirve para ilustrar los principales conceptos de un diseño organizacional basado en Team Topologies.
Vista desde arriba, una organización que funciona bien se parece mucho a una estación de trenes. Cada convoy avanza por su carril entregando valor —como los equipos alineados al flujo—, mientras otros se ocupan de tareas más técnicas o especializadas. En los márgenes, los talleres y depósitos sostienen el sistema, igual que los equipos de plataforma, y los equipos habilitadores se mueven entre vías ayudando a que todo fluya. Cada tren mantiene su rumbo porque no tiene que ocuparse de todo: la estructura está pensada para proteger su atención, reducir la carga cognitiva y dejar espacio para avanzar.