Antes de adoptar IA, reorganiza tus equipos en torno a flujos de valor

Antes de meter IA en tu empresa hay un movimiento que rinde más que cualquier herramienta o modelo que elijas: reorganizar los equipos técnicos en torno a los flujos de valor. He visto demasiadas empresas comprar las herramientas, desplegar los modelos, formar a la gente — y que la entrega siga arrastrándose, con el equipo más agotado que antes. La causa de fondo casi nunca es que la IA sea débil. Es que los equipos están cortados por capas tecnológicas: frontend, backend, algoritmos, operaciones, seguridad. Una funcionalidad de extremo a extremo tiene que cruzar cuatro o cinco equipos, y en cada traspaso se pierde algo. El requisito pierde un poco. El contexto pierde un poco. El sentido de propiedad pierde un poco. Si los límites del equipo están bien puestos, la IA tiene un terreno donde amplificarse. Si están mal, la IA solo acelera la deuda sobre una estructura rota.

Este artículo expone un método de diseño organizativo que puedes ejecutar — Team Topologies (Skelton y Pais, 2019). Tres ideas en el núcleo: cortar equipos por flujo de valor, vigilar la carga cognitiva de cada equipo y tratar la plataforma interna como producto. Lo desglosamos con un escenario real de manufactura.

Un CIO del sector (caso anonimizado de un proyecto real) me contó lo siguiente. Sacar a producción una funcionalidad de inspección de calidad con IA no era difícil técnicamente: cámaras que detectan defectos, modelo ya disponible. Lo difícil era entregar. El equipo de frontend construía la interfaz, el de MES modificaba el flujo de órdenes de trabajo, el de algoritmos desplegaba el modelo, el de operaciones gestionaba los servidores, y el de seguridad tenía que revisarlo encima de todo. Una funcionalidad, 5 equipos, 4 traspasos formales, 3 meses de arrastre. Nadie holgazaneaba. Cada traspaso simplemente dejaba algo en el suelo.

1. La ley de Conway solo cuenta la mitad

La ley de Conway dice lo siguiente: la arquitectura de un sistema refleja la estructura de comunicación del equipo que lo construye. Si divides tus equipos en frontend y backend, obtendrás un sistema con frontend y backend separados. El sistema crece tomando la forma en que se comunican los equipos. La evidencia empírica lo ha confirmado una y otra vez.

Pero Conway solo nos dijo que esto ocurre. No nos dijo cómo diseñar los equipos para que una buena arquitectura crezca por sí sola. Skelton y Pais cerraron ese hueco con Team Topologies (2019): cuatro tipos básicos de equipo, tres modos de interacción y un principio que atraviesa todo — vigilar la carga cognitiva.

2. Los cuatro tipos de equipo: opciones para una reorganización, no términos para memorizar

Recorro estos cuatro tipos como opciones que puedes invocar durante una reorganización. No hace falta que memorices definiciones.

Equipos alineados al flujo — la fuerza de trabajo de tu organización, y la gran mayoría de ellos. (El libro dice “most”, sin proporción fija.) Un “flujo” es una corriente continua de valor. Un equipo alineado al flujo es responsable de un tramo de esa corriente de extremo a extremo: entiende el requisito, lo construye, lo despliega y lo opera. Una sola prueba te dice si un equipo cuenta: ¿puede poner valor en manos del usuario sin depender de otro equipo? Volvamos a ese CIO. Si su funcionalidad de inspección inteligente hubiera pertenecido a un único “equipo de flujo de inspección” — con gente que sabe de frontend, de integración con MES, de despliegue de modelos y de operaciones, todos en un mismo equipo — la funcionalidad se entrega con cero traspasos. Esa es la forma que debería tener.

El problema más común en las grandes empresas es que el sistema corre de extremo a extremo mientras los equipos están cortados en capas tecnológicas horizontales. Cada entrega de extremo a extremo tiene que enhebrar las fronteras de reporting de varios equipos. Cambias de sector y el patrón se mantiene, aunque cambien los nombres. En finanzas, una funcionalidad de riesgo crediticio tiene que cruzar cuatro grupos: app, sistema central, modelo de riesgo y datos. E-commerce y telecom exprimen el mismo dolor con palabras distintas: una promoción cruza catálogo, transacciones, marketing y almacén; un cambio de tarifa cruza canal, facturación, CRM y red. Siempre que equipos cortados en horizontal intentan servir un flujo de valor que corre en vertical, los traspasos se multiplican. Esa es la enfermedad.

Equipos de plataforma — allanan el camino para los equipos alineados al flujo. Un equipo de plataforma suministra infraestructura, CI/CD y servicios compartidos para que los equipos alineados al flujo obtengan la capacidad por autoservicio, en vez de abrir un ticket y esperar. Una prueba: ¿tu plataforma interna se gestiona como un producto — con usuarios, hoja de ruta, SLA — o se ha deslizado hacia ser una tienda de outsourcing interno que vive de tickets? La mayoría de los departamentos de TI de las grandes empresas están atrapados en el segundo caso. Construyen una plataforma que nadie usa, los equipos de negocio la rodean y se montan lo suyo, y el equipo de plataforma decae hasta convertirse en un proveedor externo interno. Spinnaker de Netflix (entrega continua) y Backstage de Spotify (portal de desarrolladores) son los ejemplos de manual de una plataforma gestionada como producto. La gente los confunde constantemente: Spinnaker es de Netflix, Backstage es de Spotify. No los mezcles delante de tu consejo.

Equipos facilitadores — ayudan a los equipos alineados al flujo a subir de nivel, con el objetivo explícito de quedarse sin trabajo. Un equipo facilitador no entrega el negocio directamente. Eleva la capacidad de los equipos alineados al flujo: un coach que trae una nueva tecnología, un guía para una transición DevOps, un consultor en seguridad y cumplimiento. La relación con el equipo alineado al flujo es de mentor y aprendiz, no de comprador y proveedor. Para las grandes empresas, este es el papel que debería jugar un consultor externo de transformación: transferir capacidad, no fabricar una dependencia a largo plazo.

Equipos de subsistemas complejos — para los problemas duros que exigen especialización profunda. Cuando un subsistema demanda profundidad real — un motor de riesgo, un algoritmo de recomendación, criptografía, códecs de vídeo — lo separas como su propio equipo de expertos, en lugar de reventar la carga cognitiva de un equipo alineado al flujo. Estos deberían ser escasos. Una organización que brota muchos equipos de subsistemas complejos suele estar convirtiendo en silos lo que debería ser capacidad de plataforma.

Nombrar los tipos de equipo no basta. También hay que definir cómo se relacionan. Team Topologies da tres modos de interacción. Colaboración — dos equipos trabajando profundamente juntos, apto para territorio nuevo e incierto, pero intensivo en energía y solo para ráfagas cortas. X como servicio — un equipo ofrece una capacidad como producto que otro consume por su cuenta; es el modo más eficiente y debería ser el por defecto. Facilitación — exclusivo de los equipos facilitadores. La pregunta central del diseño organizativo es cómo empujar tantas interacciones como sea posible hacia “X como servicio”. Si tus equipos siguen apoyándose en “colaboración” a largo plazo, la plataforma no se ha hecho. Toma el caso del CIO: el equipo de flujo de inspección y el equipo de plataforma deberían interactuar como X como servicio. La plataforma expone un punto de entrada de CI/CD por autoservicio, y el equipo de inspección lo usa sin tener que avisar. Si cada despliegue sigue requiriendo una reunión de “colaboración” con el equipo de plataforma, falta plataforma — y el problema no es de actitud, sino de que la plataforma nunca se trató como producto.

3. Por qué ni “añadir gente” ni “añadir proceso” salvan: la carga cognitiva

Esta es la contribución más infravalorada de Team Topologies. Pone la carga cognitiva en el centro del diseño organizativo.

Un equipo de 5 a 8 personas tiene una carga cognitiva finita. Pídele a un equipo que mantenga una docena de sistemas sin relación, que dé servicio a seis o siete upstreams y que encima maneje tres frameworks nuevos a la vez — se sobrecarga. La calidad cae. La entrega se ralentiza. La gente se quema.

Esto explica por qué ese CIO estaba perplejo cuando me dijo: “Les añadí tres personas, ¿por qué seguimos lentos?” La raíz es que este grupo ya cargaba con demasiadas cosas sin relación. La cabeza era suficiente. Añadir gente solo pone más cuerpos girando en el mismo caos. Añadir proceso es peor — el proceso devora otra capa de carga cognitiva, y la gente que sí podía entregar acaba dedicando más tiempo a formularios, reuniones y aprobaciones.

La grasa más fácil de quitar en una gran empresa es la carga que la propia organización se impone: fricción entre equipos, cambios de contexto constantes, cadenas de aprobación. Cortarla no requiere tecnología nueva. Requiere dar menos vueltas.

Un caso concreto. El responsable del equipo de sistema central de un banco tenía 7 personas que daban servicio a cuatro upstreams — riesgo, atención al cliente, reporte regulatorio, marketing — mientras mantenían tres módulos inconexos. Solo con gestionar firmas cruzadas, reuniones de alineación y cambios de contexto, el equipo se gastaba casi la mitad de su energía cada día. Ponle el mejor producto de IA del mercado en las manos y no cuajará. No tienen ancho de banda cognitivo de sobra para aprender nada nuevo ni para cambiar cómo trabajan. Para rescatarlos, primero aligera: saca los módulos sin relación y deja que el equipo sea responsable de un único flujo de valor.

La regla del “Two-Pizza Team” de Amazon trata del coste de comunicación: en cuanto crece la cabeza, el número de canales de comunicación entre miembros (n(n-1)/2) explota y las decisiones se ralentizan. Team Topologies va una capa más profunda: por encima de unas 8 personas, la carga cognitiva también se descontrola. Lo que de verdad hace el diseño organizativo es dividir equipos por carga cognitiva, para que la carga de cada equipo caiga dentro de un rango soportable — no dibujar líneas de reporting por función.

Un chequeo de una frase para grandes empresas: tus “personas más ocupadas”, ¿cargan a la vez con más de 5 cosas sin relación? Si la respuesta es sí, no las salva ninguna cabeza ni ningún proceso. Hay que volver a repartir.

4. Cómo actuar: la maniobra de Conway inversa

Esta es la jugada más operativa del libro. No dibujes primero la arquitectura y luego reorganices los equipos para encajar. Cambia primero la estructura de equipos y deja que la arquitectura crezca hacia la forma que quieres.

El enfoque tradicional tiene a un arquitecto dibujando una arquitectura objetivo (“¡Vamos a microservicios!”) y exigiendo luego que los equipos se reorganicen para encajar. Esto casi siempre fracasa. La estructura existente del equipo sigue tirando de la arquitectura hacia su propia forma. La ley de Conway, haciendo lo suyo.

La maniobra de Conway inversa le da la vuelta al orden. Reorganiza primero los equipos en torno a flujos de valor — recorta equipos alineados al flujo, monta un equipo de plataforma — de modo que las fronteras del equipo se conviertan en las futuras fronteras de servicio. La arquitectura deriva entonces hacia un reparto sensato de servicios por sí sola, porque los equipos se comunicarán naturalmente a través de APIs en lugar de meter mano en una base de datos compartida.

Volvamos al CIO. No le pedí que eligiera un framework de microservicios. Le pedí algo mucho más llano: levantar “inspección” como su propio equipo de flujo. Sacar a una persona de cada uno de los equipos originales de frontend, MES, algoritmos y operaciones. Seis personas, responsables de la funcionalidad de inspección de extremo a extremo. En tres semanas pasaron tres cosas. Semana uno: descubrieron que un paso atascado en el flujo de órdenes de MES no necesitaba al equipo de algoritmos en absoluto — lo arreglaron dentro del equipo. Semana dos: decidieron por su cuenta pasar el despliegue del modelo de “hacer cola por operaciones” a autoservicio del equipo, porque el equipo de plataforma les había abierto una entrada de CI/CD por autoservicio. Semana tres: sacaron a producción la primera funcionalidad pequeña de extremo a extremo, sin cruzar ninguna frontera de equipo. No se añadió cabeza, no se cambió herramienta — las capas horizontales se habían recortado en flujos verticales. El ciclo de entrega bajó de 3 meses a 3 semanas. Hubo un beneficio inesperado: este equipo empezó a proponer mejoras por iniciativa propia, porque por primera vez veían su flujo entero y eran responsables del resultado de extremo a extremo. Cuando el trabajo cruzaba 5 equipos antes, nadie se sentía responsable del flujo de inspección completo.

Para los decisores, esta es una conclusión contraintuitiva pero de alto apalancamiento: deja de agonizar sobre el diagrama de arquitectura y empieza a cortar el organigrama. La arquitectura es el resultado. La organización es la palanca.

Quién lo está usando

Banca (sector prioritario oficial de TT + referencia de fuerte regulación). teamtopologies.com mantiene una columna de experto, “When DORA metrics meet governance in banking”. La investigación DORA que cita es contundente: las aprobaciones externas correlacionan negativamente con el lead time, la frecuencia de despliegue y el tiempo de recuperación — cuantas más aprobaciones a posteriori entre equipos, más lenta es la entrega y más lenta la recuperación de incidentes. Esto refuerza exactamente la tesis de este artículo: construir el cumplimiento dentro del equipo alineado al flujo y desplazar la aprobación hacia arriba, en lugar de depender de firmas cruzadas a posteriori. Bancos digitales británicos como ClearBank aparecen repetidamente en el ecosistema oficial. La banca es el escenario más instructivo para reorganización por flujo de valor bajo regulación intensa.
Zalando (e-commerce, el ejemplo de plataforma como producto). Su plataforma interna de desarrollo sirve como capacidad de autoservicio para los equipos alineados al flujo — un referente de plataforma como producto que la comunidad TT cita a menudo.
AutoTrader UK (clasificados de coches). Un caso real de adopción que TT cita repetidamente: reorganización por flujo de valor más productificación de la plataforma interna.
KPMG UK (se convirtió en socio oficial de soluciones TT en 2024). Lleva TT a grandes empresas y clientes financieros — señal de que TT ha entrado en la consultoría empresarial mainstream.
Netflix / Spotify (referentes espirituales de “plataforma como producto”, no casos de adopción de TT). Ambos gestionaban sus plataformas como producto mucho antes de que el libro de TT saliera en 2019, lo que valida el principio — pero no cuentan como adopciones del modelo de cuatro equipos de TT.

Referencia: teamtopologies.com/examples (biblioteca oficial de casos) · teamtopologies.com/news-blogs-newsletters/when-dora-metrics-meet-governance-in-banking (columna experta DORA en banca)

5. Cuándo no funciona

Team Topologies no es una bala de plata. Cuatro fallos habituales, cada uno mapeado con una patología real de las grandes empresas.

Renombrar sin reestructurar. Pegar la etiqueta “equipo alineado al flujo” al “grupo de frontend” mientras las líneas de reporting siguen por capa tecnológica — la ley de Conway no se preocupa por cómo llamas a las cosas. Este es el desenlace más común de una reforma cosmética en una gran empresa: etiquetas nuevas, misma vieja estructura.

El equipo de plataforma no se gestiona como producto. Sin hoja de ruta, sin experiencia de usuario. Los equipos alineados al flujo siguen rodeándolo, y la plataforma decae hasta convertirse en una tienda de outsourcing que vive de tickets.

Todo el mundo está “colaborando”. La colaboración es una interacción de alta energía, solo apta para ráfagas cortas en territorio nuevo e incierto. Depender de ella a largo plazo significa que falta plataforma. La superficie parece “gran cultura de colaboración”. La enfermedad es la ausencia de plataforma.

Los KPI no acompañaron. El organigrama cambió, pero sigues midiendo por función — líneas de código frontend, conteo de bugs — y el comportamiento del equipo regresa de golpe a la forma antigua.

Estos cuatro apuntan a un juicio: entre estructura organizativa, estructura de incentivos y arquitectura técnica, cambia uno solo sin que los otros dos sigan, y la transformación fracasa.

Una variante para sectores fuertemente regulados. Finanzas y telecom preguntarán: funciones como seguridad, cumplimiento y riesgo tecnológico están exigidas por regulación como independientes (segregación de funciones). No se pueden simplemente plegar dentro de los equipos alineados al flujo. Esto es una restricción legal dura, no inercia organizativa — no la fuerces. Pero tampoco hace falta volver a las colas de aprobación horizontales. Dos caminos. Primero, incrustar representantes de cumplimiento y seguridad dentro del equipo alineado al flujo: se sientan en el equipo a la vez que reportan en línea discontinua a la función de cumplimiento, pegados al flujo de valor pero preservando la independencia. Segundo, gestionar cumplimiento como un equipo facilitador que ayuda a los equipos alineados al flujo a construir los requisitos regulatorios dentro del flujo — controles de cumplimiento corriendo dentro del CI, por ejemplo — desplazando la aprobación hacia arriba dentro del equipo, en lugar de depender de firmas cruzadas a posteriori. Los requisitos regulatorios se convierten en la calidad integrada del equipo alineado al flujo, no en una puerta de revisión externa. Esa es la clave para que los sectores fuertemente regulados puedan fluir.

6. Quizá te lo estés preguntando

“Llevamos diez años cortados por capas técnicas, ¿una reorganización no nos va a destrozar?” Sí, pero mucho menos de lo que imaginas. No hace falta tirar abajo toda la empresa y empezar de cero. Elige el flujo de valor más atascado — normalmente el que más quejas recibe — y móntalo como un único equipo alineado al flujo piloto. Como ese CIO: 4 a 8 semanas, un equipo pequeño, y verás un cambio claro en la velocidad de entrega. Dejar que los resultados vendan la siguiente ronda funciona mucho mejor que dejar que lo venda una presentación.

“¿Qué tiene que ver esto con la transformación de IA que ya estoy corriendo?” Relación directa. La IA no arregla una organización mal alineada. Amplifica lo que ya está ahí: un equipo de alto rendimiento con IA va más rápido; un equipo desalineado con IA solo fabrica deuda más rápido. Por eso el diagnóstico organizativo va por delante de la compra de herramientas. Es también la razón por la que en mi método insignia, el Marco de coaching en 7 pasos para la transformación con IA, pongo la “evaluación de capacidades” muy al principio: primero la organización y la gente, luego las herramientas.

“¿Y si no conseguimos cubrir los cuatro tipos de equipo?” La mayoría de las organizaciones no lo consigue, ni lo necesita. Lo primero que deberías tener son equipos alineados al flujo (para garantizar la entrega de extremo a extremo) y un equipo de plataforma (para dejar de reinventar la rueda). Los equipos facilitadores y los de subsistemas complejos entran según necesidad; muchas organizaciones no los tienen al principio y está bien. No fabriques equipos solo para completar los cuatro tipos. Eso es poner el carro delante de los bueyes.

7. Lecciones para el decisor

Lección uno: antes de adoptar IA, dibuja un mapa de topología de equipos. Antes de la última herramienta de IA que introdujiste, ¿dibujaste alguna vez tu topología de equipos? Con los equipos cortados por capas tecnológicas, por fuerte que sea la IA, solo estás acelerando la deuda sobre una estructura rota. Este único chequeo puede bloquear al menos la mitad de la inversión inútil en TI de una gran empresa. Acción concreta: lista todos los equipos y marca de qué flujo de valor es responsable cada uno de extremo a extremo. Los que no puedas marcar están cortados por capa técnica, y son la prioridad para reorganizar.

Lección dos: haz un chequeo de carga cognitiva. Deja de preguntar “¿tenemos gente suficiente”. Pregunta qué equipos mantienen a la vez más de 5 sistemas sin relación, y qué personas dan servicio a más de 3 upstreams. Sacar esto a la luz es mucho más útil que añadir cabeza o proceso. La IA puede absorber parte de la carga — escribir código, buscar cosas, primer filtro — siempre que redistribuyas la carga de forma deliberada, en lugar de volcar una tarea más de “despliegue de IA” sobre un equipo ya sobrecargado.

Lección tres: gestiona la plataforma interna como producto o degenerará en outsourcing. La plataforma necesita usuarios, hoja de ruta, SLA y a alguien responsable de la tasa de adopción. En la era de la IA, esta plataforma tiene además que absorber la pasarela de modelos, la biblioteca de prompts y el entorno de ejecución de agentes — esa es la base que el artículo posterior del “marco de adopción” desplegará.

Lección cuatro: no dejes que la IA consolide las fronteras equivocadas. Esta va dedicada a las organizaciones que están introduciendo agentes de IA. Al añadir agentes al equipo, un corte equivocado se amplifica: el agente automatizará siguiendo las fronteras existentes — equivocadas — y dejará la estructura rota más firme. Antes de introducir agentes de IA, confirma que las fronteras del equipo son correctas. Este es el foco del artículo 11 de la serie.

Autochequeo inverso (responde sin maquillaje): ¿tus equipos están cortados por flujo de valor, o por frontend/backend/operaciones/seguridad? Tu persona más ocupada, ¿carga a la vez con más de 3 cosas sin relación? Una plataforma interna sin usuarios es una luz roja de plataforma fallida. Si alguna respuesta te pone incómodo, entonces antes de meter IA, reorganiza los equipos primero. Es el movimiento previo de mayor retorno.

Lo que viene

Este es el artículo 2 de la serie “La transformación de la ingeniería de software en la era de la IA” (episodio 172 de la sección “Learn AI Slowly”). Hemos ido de Conway (la organización decide la arquitectura) a Team Topologies (cómo diseñar la organización). El siguiente (n.º 3) retoma una pregunta más básica: cuando la IA hace que producir código sea casi gratis, ¿a dónde se desplaza el cuello de botella de la ingeniería de software?

Nota de la serie: esta serie sigue rastreando la evolución más reciente de las herramientas de programación con IA, la arquitectura organizativa y los paradigmas de ingeniería de software — por ejemplo, cómo cambia la ley de Conway en la era de los agentes de IA en 2026, o la madurez del ecosistema de herramientas más reciente. Sigue la serie para obtener insight que se actualiza de forma continua.

Sobre esta serie

“La transformación de la ingeniería de software en la era de la IA” es una serie de investigación profunda dirigida a CIO, CDO, CTO y líderes digitales de sectores como telecom, finanzas, manufactura y e-commerce — 15 artículos en total. Construida sobre más de 200 artículos académicos e informes de sector, ofrece referencias de decisión anotadas con nivel de evidencia.

Soy ex ingeniero de IBM, coach certificado por ICF, con experiencia de campo entregando proyectos de IA y digitales para operadores y grandes empresas. Lo que escribo aquí es el juicio de campo forjado acompañando a empresas a salir de los hoyos.

Si al terminar estás pensando “¿nuestra empresa también se parece a esto?” — he preparado un “Cuestionario de autochequeo de 20 preguntas sobre Team Topologies”, y ofrezco una llamada de diagnóstico 1 a 1 de 30 minutos para ayudarte a localizar qué flujo de valor reorganizar primero. Si lo necesitas: deja un mensaje en la cuenta oficial “AI Decision-Maker Insight” o escribe a coach@iaiuse.com.

Fuentes de referencia

Skelton, M. y Pais, M. (2019). Team Topologies. IT Revolution Press. (fuente original de los cuatro equipos / tres interacciones / carga cognitiva — fuente primaria)
Conway, M. (1968). How Do Committees Invent? Datamation.
Forsgren, Humble y Kim (2018). Accelerate. IT Revolution Press.
IT Revolution (2024). Team Topologies: Five Years of Transforming Organizations. (retrospectiva de adopción en múltiples organizaciones — secundaria) https://itrevolution.com/articles/team-topologies-five-years-of-transforming-organizations/
Netflix Spinnaker / Spotify Backstage — referentes de productificación de plataforma interna
AutoTrader UK — caso de adopción citado por TT oficial (enlace en teamtopologies.com pendiente de completar)
Biblioteca oficial de casos: https://teamtopologies.com/examples