1.2 Topologías de equipo y diseño organizacional

Panorama y motivación

La forma en que se distribuyen las personas entre equipos determina qué software puede construirse y con qué rapidez. No es una metáfora: es una consecuencia casi mecánica conocida como la ley de Conway: las organizaciones diseñan sistemas que reflejan sus propias estructuras de comunicación. Si tres equipos construyen un compilador, el resultado será un compilador de tres pasadas. Si la lógica de pagos está repartida entre un equipo de frontend, otro de backend y un tercero de base de datos, cada cambio en los pagos exige coordinación triple. Para una organización pequeña, eso es manejable. Para una grande, la forma del organigrama se convierte en la restricción dominante sobre la ingeniería, la arquitectura, la velocidad de entrega y la calidad. Por eso, diseñar la estructura de equipos es una actividad de primera clase en ingeniería, no una decisión tardía de recursos humanos.

Las topologías de equipo ofrecen un vocabulario deliberado para este diseño. En lugar de dejar que la estructura se acumule por accidente a través de reestructuraciones y ampliaciones de plantilla, las organizaciones maduras eligen tipos de equipo y modos de interacción con intención, y revisan esas elecciones conforme el sistema y el negocio evolucionan. El objetivo es mantener la carga cognitiva de cada equipo baja (la cantidad total de información que un equipo debe sostener en mente para ser eficaz) , de modo que cada equipo pueda apropiarse de su dominio de principio a fin y entregar un flujo constante de valor sin esperar constantemente a otros.

En el ámbito empresarial y público, esta disciplina es decisiva. Las organizaciones grandes tienden a expandirse en jerarquías profundas, servicios compartidos con colas interminables y cadenas de traspaso que convierten un cambio de dos días en un proyecto de dos meses. El sector público añade fronteras de contratación, equipos de contratistas y segregaciones de funciones obligatorias que fragmentan aún más la responsabilidad. El diseño explícito de topologías es la forma en que estas organizaciones recuperan el flujo: alinear equipos a los flujos de valor, construir plataformas que reduzcan la carga cognitiva y elegir patrones de interacción que hagan que las dependencias sean visibles e intencionales en lugar de ocultas y permanentes.

Principios clave

La ley de Conway es ineludible; diseña los equipos para que coincidan con la ingeniería de software que se desea (la «maniobra inversa»).
Se optimiza la carga cognitiva del equipo, no la máxima utilización individual.
Se prefieren los equipos alineados al flujo, que se apropian de un fragmento de valor de extremo a extremo.
Las plataformas existen para reducir la carga cognitiva de los equipos alineados al flujo, no para ejercer control.
Las interacciones entre equipos deben ser explícitas y escasas: colaboración, X-como-servicio o facilitación.
Se minimizan las dependencias; cada traspaso entre equipos es una cola y un riesgo.
La estructura de equipos es un diseño vivo que debe evolucionar con el sistema y el negocio.

Recomendaciones

Usar los cuatro tipos fundamentales de equipo

Las topologías de equipo definen cuatro tipos que cubren la mayoría de las necesidades. Los equipos alineados al flujo son el predeterminado: cada uno se apropia de un flujo continuo de trabajo para un producto, servicio o trayecto de usuario específico, de principio a fin. Los equipos de plataforma ofrecen productos internos (cómputo, despliegue, tuberías de datos, identidad) que los equipos alineados al flujo consumen de forma autoservida, lo cual reduce su carga cognitiva. Los equipos de habilitación son especialistas (pruebas, seguridad, observabilidad) que enseñan a los equipos alineados al flujo a desarrollar una capacidad y luego se retiran. Los equipos de subsistema complejo se apropian de componentes que exigen una experiencia profunda y específica (un motor de precios, un códec de video, un módulo criptográfico), donde no tiene sentido que cada equipo asuma ese conocimiento. La mayor parte de los equipos deberían ser alineados al flujo; los otros tres tipos existen para sostenerlos.

Aplicar la maniobra inversa de Conway

Dado que el software refleja la estructura de la organización, moldea los equipos para que produzcan el software deseado. ¿Se quiere servicios poco acoplados con límites claros? Crea equipos poco acoplados con fronteras de propiedad bien definidas. ¿Se busca una capacidad de pagos que se entregue con su propio ritmo? Forma un equipo de pagos que se apropie de ella de extremo a extremo. No combates la ley de Conway con coordinación heroica. Redibuja los límites de los equipos para que la arquitectura deseada se convierta en el camino de menor resistencia.

Gestionar la carga cognitiva de forma explícita

Un equipo solo puede dominar tanto. La carga cognitiva incluye la complejidad del dominio, las tecnologías, la carga operativa y la amplitud de los grupos de interés. Cuando un equipo se apropia de demasiados servicios no relacionados, la calidad y la velocidad se desploman por igual. Por eso, se delimita la responsabilidad de cada equipo a un dominio que pueda dominar de verdad, y se emplean plataformas y equipos de habilitación para descargar de sus hombros la complejidad indiferenciada. Los equipos deben mantenerse en torno a cinco o nueve personas: lo suficientemente pequeños para comunicarse con facilidad y, por así decirlo, caber en un par de pizzas.

Elegir los modos de interacción con deliberación

Se limitan las interacciones entre equipos a tres modos. La colaboración es un trabajo cercano y de alto ancho de banda entre dos equipos durante un periodo acotado; es poderosa para la exploración, pero costosa, así que se mantiene temporal. X-como-servicio es una relación limpia de proveedor y consumidor con una interfaz bien definida, ideal para el consumo de plataforma a gran escala. La facilitación es cuando un equipo ayuda a otro a aprender; es lo que hacen los equipos de habilitación. Se nombra el modo para cada relación interequipo importante y se lee una colaboración prolongada entre los mismos dos equipos como una señal de que su frontera está en el lugar equivocado.

Elegir un modelo operativo para las funciones transversales

La seguridad, los datos, el diseño y disciplinas similares pueden organizarse de tres maneras: centralizada (un equipo la posee para todos), federada (especialistas integrados a tiempo parcial, coordinándose a través de un gremio) o integrada (un especialista dedicado dentro de cada equipo alineado al flujo). La centralización aporta coherencia y profundidad, pero se convierte en un cuello de botella. La integración ofrece velocidad y contexto, pero arriesga la inconsistencia y la duplicación. La federación (a menudo un modelo de hub y radios o comunidad de práctica) se sitúa en el punto intermedio. Se elige por función y por escala. La mayoría de las grandes organizaciones optan por la federación en estas disciplinas, con un núcleo central reducido que establece los estándares.

Invertir en inner-source

El inner-source introduce los patrones de colaboración del código abierto dentro de la organización: repositorios internos compartidos, pautas de contribución publicadas, revisión de código entre límites de equipo y mantenedores claros. Cuando un equipo necesita un cambio en un componente de otro equipo, puede contribuirlo directamente en lugar de abrir un ticket y esperar en cola. Esto alivia las dependencias entre equipos sin disolver la propiedad y difunde el conocimiento y los estándares de forma natural entre una amplia población de ingeniería.

Compromisos: ventajas e inconvenientes

Modelo para funciones transversales	Ventajas	Inconvenientes
Centralizado (un equipo para todos)	Coherencia, experiencia profunda, estándares claros	Cuello de botella, colas, pérdida de contexto del producto
Federado (hub y radios, gremios)	Equilibra coherencia y velocidad; comparte conocimiento	Exige disciplina de coordinación; la responsabilidad puede difuminarse
Integrado (especialista por equipo)	Rápido, rico en contexto, alta apropiación	Duplicación, inconsistencia, difícil de dotar a escala

Tipo de equipo	Ideal para	Riesgo si se abusa
Alineado al flujo	La mayoría de la entrega de producto y servicio	Ninguno; debería predominar
De plataforma	Reducir la carga cognitiva compartida	Se convierte en una torre de marfil que ejerce control
De habilitación	Difundir una capacidad de forma temporal	Se transforma en una dependencia permanente
De subsistema complejo	Dominios de especialización genuinamente profundos	Se usa como excusa para monopolizar trabajo ordinario

El compromiso que se repite es la autonomía frente a la coherencia. Los equipos plenamente autónomos avanzan rápido, pero se dispersan en estándares, herramientas y postura de seguridad. El control plenamente centralizado mantiene la uniformidad, pero estrangula el flujo. El buen diseño topológico encuentra la junta: autonomía para la entrega de los equipos alineados al flujo, más unos estándares centrales mínimos y plataformas de camino empedrado (herramientas predeterminadas bien soportadas que hacen que la opción conforme sea la más fácil) para aquello que genuinamente debe ser consistente.

Preguntas para debatir con el equipo

¿Qué señales concretas indicarán que la carga cognitiva de un equipo es excesiva, antes de que la calidad se deteriore? «Acotar cada equipo a un dominio que pueda dominar» es fácil de decir y difícil de ejecutar sin evidencia, porque la carga cognitiva permanece invisible hasta que la entrega y la fiabilidad se degradan. Se observan síntomas medibles: el número de servicios o repositorios no relacionados que un equipo posee, cuánto tarda la incorporación de un nuevo integrante, cuántos dominios un solo ingeniero debe alternar a lo largo de la semana y la tasa creciente de incidentes en los márgenes de la responsabilidad de un equipo. En una organización grande, esto importa porque los equipos sobrecargados se convierten en silencio en cuellos de botella que ningún diagrama de reestructuración predice. Se traen esos números al debate, junto con la percepción propia del equipo sobre lo que puede y no puede sostener en mente. Si las señales indican sobrecarga, el movimiento consiste en descargar el trabajo indiferenciado en una plataforma o un equipo de habilitación, no en exigir más heroísmos.
¿Vale realmente la pena una reestructuración en este caso, o se está alimentando una adicción a las reestructuraciones? Redibujar los límites para aplicar la maniobra inversa de Conway es poderoso, y toda reestructuración también destruye la estabilidad que los equipos necesitan para cohesionarse y reinicia el conocimiento del dominio tan duro de adquirir. Las consideraciones en competencia son el costo de coordinación constante de la estructura actual frente al costo único y el impacto moral del cambio. En entornos empresariales y públicos, las fronteras de contratación, los equipos de contratistas y las segregaciones de funciones obligatorias hacen que las reestructuraciones sean más lentas y más caras, así que el umbral debe ser más alto. Se traen evidencias de la espera derivada de dependencias: cuántas iniciativas están bloqueadas esperando a otro equipo y durante cuánto tiempo. Se reorganiza cuando esa espera es estructural y grande, y se resiste a la reorganización cuando el dolor es temporal o podría resolverse más baratas con contribuciones de inner-source y interfaces más claras.
¿Qué evento disparará el tránsito entre modelos integrados, federados y centralizados para seguridad, datos y diseño? La recomendación del capítulo es elegir por función y por escala; la disciplina más difícil es decidir de antemano qué crecimiento o qué riesgo obligará a reconsiderar esa elección. Un modelo que encaja para cincuenta ingenieros puede convertirse en un cuello de botella o un desastre de coherencia para quinientos, y las empresas y los organismos públicos en particular deben nombrar los estándares que un pequeño núcleo central sostendrá siempre. Se traen los tiempos de cola actuales y las brechas de coherencia de cada función: un equipo central de seguridad con colas de revisión de varias semanas es una señal para federar, mientras que especialistas integrados que producen modelos de datos incompatibles es una señal para añadir un núcleo central de estándares. Se decide el disparador ahora (un umbral de longitud de cola o un hallazgo de auditoría) , para que el cambio sea una evolución planificada en lugar de una reacción a la crisis. La respuesta determina dónde se invierte en caminos empedrados y referentes frente a un hub central.
¿Cómo se sabrá si el equipo de plataforma está reduciendo genuinamente la carga cognitiva o se está convirtiendo en un custodio disimulado? Una plataforma existe para hacer que la opción conforme y fiable sea la más fácil a través del autoservicio, y el mismo equipo puede derivar hacia imponer herramientas, revisar manualmente cada solicitud y añadir la fricción que estaba destinada a eliminar. En una organización grande, esta distinción decide si la inversión en plataforma se recupera o si se convierte en un cuello de botella central detrás del cual cada equipo alineado al flujo debe hacer cola. Las consideraciones en competencia son la coherencia y el control por un lado, y la autonomía del consumidor y el flujo por el otro. Se traen evidencias que un consumidor reconocería: cuánto tarda un equipo alineado al flujo en obtener un nuevo entorno o tubería de forma autoservida sin abrir un ticket, la proporción de acciones en autoservicio frente a las mediadas por un humano, y la adopción de la plataforma medida por los equipos que la eligen en lugar de los que se ven obligados a usarla. En entornos empresariales y públicos, se exige que la plataforma genere evidencia de auditoría y cumplimiento de forma automática en lugar de a través de puertas de revisión manual, porque una plataforma que cumple las reglas de segregación de funciones insertando un revisor humano ha recreado el cuello de botella para el que fue financiada.
¿Qué relaciones entre equipos se han instalado en una colaboración permanente, y qué convertiría cada una en una interfaz de servicio limpia o en un límite redrawn? El modo de colaboración está pensado para ser intenso y temporal, y un dúo que no termina suele ser una señal de que la propiedad está en el lugar equivocado o de que la interfaz entre dos equipos nunca se hizo explícita. Esto importa a escala porque la colaboración permanente sin nombre es donde se esconde el costo de coordinación: no aparece en ningún organigrama, pero grava cada cambio que los dos equipos tocan. Las consideraciones en competencia son el valor de exploración de mantenerse cerca frente al flujo que se gana al transformar la relación en un contrato X-como-servicio con una interfaz definida, o al fusionar la responsabilidad en un solo equipo. Se trae la lista de pares de equipos que han colaborado de forma continua más de un trimestre, los cambios que requirieron a ambos equipos en los últimos meses y si una interfaz estable entre ellos podría escribirse. En contextos empresariales y públicos, donde las fronteras de los contratistas y los lotes de contratación pueden congelar un traspaso durante años, se nombra qué relaciones pueden convertirse con una interfaz y contribuciones de inner-source y cuáles están fijadas contractualmente y deben gestionarse como dependencias explícitas.
¿Cómo se sabrá, cuando un equipo de habilitación ayuda a otro a construir una capacidad, que ha tenido éxito y puede retirarse en lugar de convertirse en una dependencia permanente? Los equipos de habilitación están pensados para enseñar a un equipo alineado al flujo a dominar pruebas, seguridad u observabilidad y luego marcharse; sin una condición de salida explícita, la relación de coaching se endurece en un servicio permanente que el equipo receptor nunca asimila de verdad. En una organización grande, esta es la diferencia entre extender una capacidad a decenas de equipos y crear un nuevo cuello de botella compartido que escala peor cada año. Las consideraciones en competencia son la profundidad y la coherencia que un equipo especialista aporta frente a la autonomía y la apropiación de extremo a extremo que se busca construir en los equipos alineados al flujo. Se traen evidencias de transferencia de capacidad: si el equipo receptor ya maneja el trabajo sin la presencia del equipo de habilitación, cuántos equipos un grupo de habilitación fijo tiene comprometidos simultáneamente y cuánto tiempo lleva cada intervención superando su punto de traspaso previsto. En entornos empresariales y públicos, donde una habilidad escasa puede quedar atrapada tras un único equipo central o un único contrato, se decide de antemano cómo se financia la transferencia de capacidad y los referentes, para que la experiencia se difunda en los equipos de entrega en lugar de quedar bloqueada detrás de una cola sobre la que cada auditoría y cada lanzamiento debe esperar.

Perspectiva sectorial

Startup. Con un puñado de ingenieros y poca holgura, la topología adecuada es un único equipo alineado al flujo que se apropia de todo el producto de principio a fin, que es exactamente lo correcto a esa escala: sin traspasos, sin costo de coordinación, todos compartiendo el mismo contexto. Los problemas empiezan cuando se contrata a un «DevOps» solitario y a un «QA» separado y se recrean accidentalmente silos funcionales, de modo que cada lanzamiento ahora espera a dos personas. Se corrige el rumbo tratando a esas contrataciones como una capacidad integrada de plataforma y pruebas dentro del equipo único, en lugar de puertas por las que el trabajo debe pasar. A ese tamaño, la topología más económica es la que mantiene a todos en un mismo flujo.

Pequeña empresa. No se puede dotar un equipo de plataforma o de habilitación dedicado, así que se compra la plataforma: se usan servicios cloud gestionados, tuberías alojadas y herramientas de seguridad de catálogo para descargar la carga cognitiva indiferenciada de uno o dos equipos. Las preocupaciones transversales como la seguridad y los datos se formulan como cosas que se configuran y se consumen, no como una función que se construye. Se reserva cualquier propiedad a medida para el único subsistema complejo que genuinamente distingue, y se deja que los proveedores se encarguen del resto.

Gran empresa. A escala, el problema es el costo de coordinación entre muchos equipos, así que la topología se hace un diseño explícito y gobernado: una taxonomía compartida de los cuatro tipos de equipo, modos de interacción nombrados, una plataforma de camino empedrado y inner-source para aliviar las colas entre equipos. Se rastrea la espera derivada de dependencias y la carga cognitiva del equipo como métricas de cartera, y se ejecutan reestructuraciones como evoluciones deliberadas con un umbral alto en lugar de un reflejo anual. Un núcleo central reducido sostiene los estándares que deben ser consistentes, mientras los equipos alineados al flujo conservan autonomía en la entrega.

Sector público. Las normas de contratación, las fronteras de los contratistas y las segregaciones de funciones obligatorias fragmentan la propiedad, así que la topología se diseña para cumplir esas restricciones a través de herramientas e interfaces claras en lugar de traspasos humanos. Se favorecen los modelos federados con un pequeño núcleo de estándares y una plataforma que genere evidencia de auditoría y cumplimiento de forma automática, para que la segregación de funciones se imponga por medio de tuberías en lugar de colas de revisión. Se documentan los límites de equipo, los modos de interacción y el modelo operativo de forma abierta, para que la estructura sea transparente ante auditores, organismos de supervisión y la ciudadanía que la financia.

Ejemplos

Startup. Una startup de diez personas tiene un único equipo alineado al flujo que se apropia de todo el producto de principio a fin, que es exactamente lo correcto a su escala: sin traspasos, sin costo de coordinación, todos compartiendo el mismo contexto. Los problemas empiezan cuando contratan a un «DevOps» dedicado y a un «QA» separado y recrean accidentalmente silos funcionales, de modo que cada lanzamiento ahora espera a dos personas. Corrigen el rumbo tratando a esas contrataciones como una capacidad integrada de plataforma y pruebas dentro del equipo único, en lugar de puertas de paso. A ese tamaño, la topología más económica es la que mantiene a todos en un mismo flujo.

Gran empresa. El proceso de pago de un gran minorista era lento de modificar porque el frontend, el backend y la lógica de cumplimiento estaban repartidos en tres equipos organizados por función, lo que obligaba a cada cambio a pasar por tres listas de trabajo. Aplicando la maniobra inversa de Conway, se reorganizaron en equipos alineados al flujo alrededor de trayectos del cliente («navegación», «carrito y pago», «posventa»), cada uno con su porción de extremo a extremo, respaldados por un equipo de plataforma que ofrecía despliegue y observabilidad como servicio. Los cambios en el pago que antes tomaban un trimestre empezaron a entregarse en días, porque la coordinación que antes se extendía entre equipos ahora ocurría dentro de uno.

Sector público. Una agencia tributaria del sector público operaba un equipo central de seguridad que revisaba cada lanzamiento, creando una cola de varias semanas que retrasaba correcciones críticas. Cambiaron a un modelo federado: un pequeño equipo central de seguridad establecía estándares y ofrecía un «camino empedrado» de tuberías preaprobadas y escaneadas automáticamente, mientras referentes de seguridad integrados a tiempo parcial en cada equipo de entrega asumían las decisiones cotidianas. La plataforma generaba evidencia de cumplimiento de forma automática. Los requisitos obligatorios de segregación de funciones se seguían cumpliendo, pero a través de herramientas e interfaces claras en lugar de un cuello de botella humano, lo que redujo drásticamente el tiempo de entrega de lanzamientos y mejoró la preparación para auditorías.

Caso de negocio: motivaciones, ROI y TCO

Se paga por un mal diseño de equipos en sobrecosto de coordinación, y ese sobrecosto crece más rápido que linealmente con el número de equipos que deben sincronizarse para un cambio típico. Cada traspaso es una cola con tiempo de espera, una transferencia de contexto que pierde información y una nueva oportunidad de malentendido. Cuando un cambio rutinario exige que tres equipos alineen sus hojas de ruta, el costo real no es la suma de su trabajo; es el costo mucho mayor de programar, esperar y rehacer. Se redibujan los límites para que la mayoría de los cambios quepan dentro de la apropiación de un solo equipo, y ese sobrecosto simplemente desaparece.

El costo de adopción es real. Las reestructuraciones son disruptivas, y construir plataformas y prácticas de inner-source exige inversión inicial antes de que el rendimiento aparezca. Pero el costo de no adoptar se compone. Las organizaciones que dejan que la estructura se acumule por accidente apilan cadenas de traspaso, equipos de servicio compartido con colas de un trimestre completo y arquitecturas fosilizadas por el organigrama. Para hacer el caso a la dirección, se mide la espera derivada de dependencias: cuántas iniciativas activas están bloqueadas esperando a otro equipo y durante cuánto tiempo. Las inversiones en plataforma y topología suelen recuperarse al convertir esa espera en flujo, lo que se manifiesta como tiempos de entrega más cortos y mayor rendimiento sin añadir plantilla.

Antipatrones y errores

Ignorar la ley de Conway: diseñar una arquitectura que la estructura organizativa no puede entregar.
Silos funcionales: equipos separados de frontend, backend, QA y operaciones que deben coordinarse para cualquier cambio.
Cuello de botella de servicios compartidos: un equipo central detrás del que todos los proyectos deben hacer cola.
Plataforma como custodio: un equipo de plataforma que impone en lugar de servir, añadiendo fricción en lugar de eliminarla.
Sobrecarga cognitiva: equipos que se apropian de sistemas extensos y no relacionados que no pueden dominar.
«Colaboración» permanente: dos equipos perpetuamente entrelazados, que señalan un límite mal colocado.
Adicción a la reestructuración: reorganizar constantemente, destruyendo la estabilidad que los equipos necesitan para cohesionarse.

Modelo de madurez

Nivel 1, Iniciar. Los equipos se forman por accidente, por plantilla o por jerarquía heredada; nadie nombra tipos de equipo ni modos de interacción; los silos funcionales y los cuellos de botella de servicio compartido están por todas partes y las dependencias se ocultan hasta que bloquean un lanzamiento.
Nivel 2, Desarrollar. Algunos equipos alineados al flujo existen y aparece un primer esfuerzo de plataforma o inner-source, pero el patrón se aplica de forma desigual: unos cuantos equipos se apropian de su porción de principio a fin mientras otros siguen haciendo cola detrás de funciones centrales, y la carga cognitiva se discute de forma anecdótica en lugar de gestionarse.
Nivel 3, Estandarizar. Los cuatro tipos de equipo y los tres modos de interacción están documentados y se usan de forma deliberada en toda la organización; las plataformas y el inner-source alivian las dependencias entre equipos; un modelo operativo para seguridad, datos y diseño está elegido y escrito, y los nuevos equipos se forman según esos estándares en lugar de improvisación.
Nivel 4, Gestionar. La topología se mide y controla frente a líneas de base: los equipos rastreamos la carga cognitiva, la espera derivada de dependencias (iniciativas bloqueadas esperando a otro equipo y por cuánto tiempo), las proporciones de autoservicio y adopción de la plataforma, la duración de los modos de interacción y las métricas de flujo de entrega como tiempo de entrega y frecuencia de cambios. Los umbrales disparan acciones (por ejemplo, una longitud de cola que obliga a federar una función o una colaboración permanente que marca un límite mal colocado) , de modo que las decisiones se basan en evidencia en lugar de opinión.
Nivel 5, Orquestar. El diseño de equipos mejora continuamente y se integra con la planificación de arquitectura, producto y riesgo; la organización remoldea los límites a medida que el sistema y el negocio evolucionan, retira las intervenciones de habilitación una vez que la capacidad se ha transferido y reequilibra la inversión en plataforma conforme la carga cognitiva se desplaza, manteniendo el flujo veloz como una propiedad adaptativa y permanente en lugar de una reestructuración puntual.

Ideas para el debate

Para un cambio típico, ¿cuántos equipos deben coordinarse y por qué?
¿Qué equipos cargan demasiada carga cognitiva y qué podría una plataforma descargar?
¿En qué lugares se está combatiendo la ley de Conway en lugar de redibujar límites?
¿Los equipos de plataforma sirven a los equipos alineados al flujo o les ejercen control?
¿Deben seguridad, datos y diseño ser centralizados, federados o integrados para nosotros ahora mismo?
¿Qué «colaboraciones temporales» se han convertido en silencio en dependencias permanentes?

Ideas clave

La estructura organizativa determina la arquitectura y la velocidad de entrega; se diseña con deliberación.
Se usan los cuatro tipos de equipo, con el alineado al flujo como predeterminado y los demás en apoyo.
Se aplica la maniobra inversa de Conway para hacer de la arquitectura deseada el camino más fácil.
Se gestiona la carga cognitiva; se acota cada equipo a un dominio que puede dominar.
Se limitan y nombran los modos de interacción entre equipos; se tratan las dependencias persistentes como defectos de límite.
Se eligen modelos centralizados, federados o integrados para las funciones transversales según la escala, y se usa inner-source para aliviar las colas.

Referencias y lectura complementaria

Matthew Skelton y Manuel Pais, Team Topologies: Organising Business and Technology Teams for Fast Flow
Melvin Conway, «How Do Committees Invent?» (el origen de la ley de Conway)
Nicole Forsgren, Jez Humble y Gene Kim, Accelerate
Will Larson, An Elegant Puzzle: Systems of Engineering Management
Sam Newman, Building Microservices (sobre el alineamiento de servicios a equipos)
Danese Cooper y Klaas-Jan Stol, Adopting InnerSource, y los patrones del InnerSource Commons
Frederick Brooks, The Mythical Man-Month (sobre la sobrecarga de comunicación)