Team Topologies

Ley de Conway y maniobra inversa

Las organizaciones diseñan sistemas que copian sus estructuras de comunicación. La maniobra inversa de Conway consiste en diseñar primero los equipos y sus interfaces para obtener la arquitectura deseada. Si quieres servicios de Originación y Cobranza independientes, necesitas equipos independientes que los posean.

Cuatro tipos de equipo

Tipo	Misión	Ejemplo
Stream-aligned	Entregar valor de extremo a extremo en un flujo de negocio	Equipo de Originación móvil
Platform	Ofrecer servicios internos self-service que reducen carga	Plataforma de despliegue y observabilidad
Enabling	Ayudar temporalmente a otros equipos a adquirir capacidades	Coaches de pruebas o de seguridad
Complicated-subsystem	Poseer una pieza que requiere especialización profunda	Motor de scoring y modelos de riesgo

La mayoría de los equipos deberían ser stream-aligned; los demás existen para que estos fluyan.

Tres modos de interacción

Modo	Cuándo	Duración
Collaboration	Descubrir algo nuevo juntos	Temporal, con fecha de fin
X-as-a-Service	Consumir algo estable con interfaz clara	Permanente
Facilitating	Un equipo ayuda a otro a aprender	Temporal

Una colaboración que nunca termina es una señal de que el límite entre equipos está mal trazado.

Carga cognitiva

Distingue tres tipos: intrínseca (propia de la tarea), extrínseca (entorno, herramientas, procesos) y pertinente (aprendizaje del dominio que aporta valor). Una plataforma debe reducir la extrínseca. Pregunta útil en una retrospectiva: «¿cuántos de los servicios que poseemos podríamos operar a las 3 de la madrugada con confianza?».

Plataforma como producto

• Tiene usuarios (los equipos), un roadmap y métricas de adopción y satisfacción.
• Es opcional y atractiva: si los equipos están obligados a usarla, se pierde la señal de calidad.
• Ofrece un thinnest viable platform: a veces basta una wiki con plantillas y un pipeline común.
• Portales como Port o Backstage son la interfaz, no la plataforma.

Team API

Cada equipo publica cómo se trabaja con él, igual que un servicio publica su API:

Sección	Contenido de ejemplo
Misión	«Llevar al cliente de la solicitud al desembolso en menos de 24 h»
Tipo de equipo	Stream-aligned
Servicios que posee	api-solicitudes, app-originacion, topic solicitud-eventos
Cómo pedirnos algo	Canal #originacion-ayuda, plantilla de issue, SLA de respuesta
Versionado y contratos	OpenAPI en docs/, eventos con esquema en el registro
Interacciones actuales	Colaboración con Riesgos hasta el 31/12; X-as-a-Service con Plataforma
Prácticas	Trunk-based, despliegue continuo, guardia semanal

Revisar las Team APIs de todos los equipos en un mismo mapa hace visibles dependencias y colaboraciones que nadie había decidido.

Señales de carga cognitiva excesiva

Señal	Posible causa
El equipo posee más servicios de los que puede explicar	Límites demasiado amplios
Cada cambio requiere coordinar con otros dos equipos	Límite mal trazado o falta de plataforma
La guardia es temida y los incidentes tardan en resolverse	Demasiadas tecnologías distintas
El onboarding tarda meses	Dominio muy extenso o documentación ausente
Las personas expertas son cuellos de botella permanentes	Falta un enabling team o un complicated-subsystem

Una encuesta corta y periódica («¿entiendes bien el software que tu equipo posee?», «¿cuánto tiempo dedicas a herramientas en lugar de al producto?») convierte estas señales en datos.

Ejemplo: reorganizar por flujos

ANTES (por capas técnicas)
  Frontend ── Backend ── Base de datos ── Operaciones
  Cada funcionalidad cruza 4 equipos y 3 colas de espera.

DESPUÉS (por flujos de valor)
  Stream: Originación   Stream: Cobranza   Stream: Pagos
        │                     │                │
        └──── consumen X-as-a-Service ─────────┘
              Plataforma (despliegue, observabilidad, datos)
  Enabling: Calidad y pruebas (temporal)
  Complicated subsystem: Motor de scoring

Cómo hacer la transición

1. Mapear el estado actual: equipos, servicios que poseen, dependencias y esperas en el flujo.
2. Elegir un flujo piloto con dolor visible y patrocinio de negocio.
3. Formar el equipo stream-aligned con todas las capacidades necesarias para entregar sin traspasos.
4. Definir la plataforma mínima que ese equipo necesita y su modo de interacción.
5. Medir lead time y dependencias externas antes y después.
6. Extender a otros flujos con lo aprendido; revisar cada trimestre.

Rol de la gerencia

Diseñar equipos es una decisión de arquitectura: involucra a arquitectura y a negocio, no solo a recursos humanos. Mantén los equipos estables (5–9 personas) y mueve el trabajo hacia los equipos, no las personas hacia el trabajo. Evita reorganizaciones frecuentes: cada cambio reinicia la confianza y el conocimiento compartido.

Criterios de implementación

Dibuja el mapa actual de equipos, tipos e interacciones antes de proponer cambios. Alinea los equipos stream-aligned con bounded contexts. Revisa los modos de interacción cada trimestre y mide el flujo con DORA y la experiencia con SPACE.