Antes de comenzar

Tu arquitectura de software no es “diseñada” por tu equipo técnico, sino que “crece” según tu estructura organizacional. Esta ley propuesta en 1968 está siendo constantemente validada en la era de la IA.
Estudios empíricos de la Escuela de Negocios de Harvard demuestran que la distancia organizacional predice con mayor precisión la tasa de defectos en software que la complejidad del código. Lo que crees que es “deuda técnica” es, en esencia, probablemente “deuda organizacional”.
El imperio de microservicios de Amazon, el modelo de equipos de Spotify, el dilema de Siri de Apple: tres empresas de billones de dólares ilustran la misma ley mediante destinos radicalmente distintos.
Los agentes de IA están entrando en los organigramas. Cuando los “nodos” dentro de tu equipo ya no son solo humanos, la Ley de Conway será reescrita de formas que ni siquiera imaginas.

En 1968, un programador desconocido escribió un artículo que fue rechazado por Harvard Business Review con la razón de que “no probaba su argumento”. 56 años después, la idea central de ese artículo se convirtió en una ley universal reconocida en toda la industria del software — y en 2026, mientras la IA reconfigura todo, es más crucial que nunca.

1. ¿Cómo un artículo rechazado se convirtió en la “ley de la gravedad” de la ingeniería de software?

El profeta rechazado por HBR

En abril de 1968, Melvin Conway publicó en la revista Datamation un artículo con un título aparentemente modesto: How Do Committees Invent? (¿Cómo inventan los comités?).
La afirmación central de este artículo se resume en una sola frase, suficiente para hacer insomne a cualquier CTO:

“Las organizaciones que diseñan sistemas tienden a producir diseños que son copias estructurales de las comunicaciones dentro de dicha organización.”

Traducido al lenguaje cotidiano: tu organigrama corporativo es la versión exacta de tu arquitectura de software.

Conway describió en su artículo un caso elegante: una empresa asignó a ocho personas divididas en dos equipos para construir dos compiladores: un equipo de cinco y otro de tres. ¿El resultado? El equipo de cinco desarrolló un compilador de cinco etapas; el equipo de tres, uno de tres etapas. No porque la tecnología lo requiriera, sino porque cada persona necesitaba “poseer” su propia unidad de trabajo.

Conway expresó esta relación en términos matemáticos como “homomorfismo” (homomorphism): existe una correspondencia estructural que preserva la forma entre la organización y el diseño del sistema. No es una coincidencia. No es casualidad. Es una ley casi matemáticamente inevitable.

Ironizadamente, Conway originalmente envió este artículo a la Harvard Business Review, pero fue rechazado por los editores con la razón de que “no probaba su argumento”. Siete años después, Fred Brooks citó solemnemente esta idea en su obra clásica “The Mythical Man-Month” y la bautizó formalmente como “Ley de Conway” (Conway’s Law).
Desde entonces, una observación rechazada por las principales revistas comerciales se convirtió en una de las leyes más citadas en la ingeniería de software.
## La “sentencia final” de Martin Fowler
Si Conway fue el Copérnico que planteó la hipótesis, entonces las investigaciones empíricas de las últimas dos décadas han sido el telescopio.
En 2022, el científico principal de ThoughtWorks, Martin Fowler, escribió una evaluación ampliamente difundida en la industria: “Si hay una sola ley en el campo de la arquitectura de software que todos los practicantes acepten, es la Ley de Conway. Es lo suficientemente importante como para haber influido en cada sistema que he visto; es lo suficientemente poderosa como para que cualquier intento de oponerse a ella esté destinado al fracaso.”
Esto no es una especulación teórica de un académico en su torre de marfil. Fowler ha observado repetidamente, en cientos de consultorías en empresas de todo el mundo, el mismo fenómeno: el organigrama de una organización es la sombra del diseño del software, independientemente de si la gerencia lo reconoce o no.

Aquí hay un matiz sutil pero crucial que mucha gente pasa por alto: Fowler dijo que “cualquiera que intente oponerse a ella está destinado al fracaso”, no “cualquiera que intente utilizarla“. ¿Cuál es la diferencia? Oponerse a la Ley de Conway significa imponer cambios arquitectónicos sin modificar la estructura organizacional; en cambio, utilizarla significa ajustar primero la organización para permitir que la arquitectura “crezca naturalmente”.
Esta diferencia determina el éxito o fracaso de los proyectos de transformación digital. En la segunda parte de esta serie, al discutir Team Topologies, profundizaremos en la estrategia clave llamada “Maniobra de Conway Inversa” (Inverse Conway Maneuver), que consiste esencialmente en aprovechar, no oponerse, a esta ley.

II. Del laboratorio al campo de batalla: tres estudios confirman esta ley

La “hipótesis del espejo” de Harvard Business School

En 2012, MacCormack y sus colegas de Harvard Business School publicaron un estudio fundamental conocido en la academia como la “hipótesis del espejo” (Mirroring Hypothesis).

Su método fue ingenioso: compararon software comercial y software de código abierto que realizaban exactamente la misma función. El software comercial fue desarrollado por equipos corporativos jerárquicos; el software de código abierto, por comunidades descentralizadas.

Como predijo la Ley de Conway: los productos desarrollados por organizaciones con baja acoplamiento son significativamente más modularizados. Equipos empresariales con alto acoplamiento, incluso cuando persiguen deliberadamente un diseño modular, terminan produciendo sistemas que reflejan su estructura organizacional: altamente acoplados.

La estructura organizacional actúa como un “campo gravitacional”: puedes resistirla temporalmente, pero con el tiempo, la arquitectura del sistema siempre se ve arrastrada hacia una forma isomórfica con la organización.

¿Cuál es la verdadera lección para los tomadores de decisiones empresariales? Cuando tu equipo técnico te dice repetidamente “necesitamos reestructurar”, lo que realmente necesita “reestructurarse” puede no ser el código, sino la organización. Pero, ¿cómo distinguir entre “deuda técnica” y “deuda organizacional”? Requiere un método sistemático de diagnóstico — en el artículo 12, “Marco de toma de decisiones para la adopción de herramientas de IA empresarial”, proporcionaremos un modelo de evaluación completo.

El “experimento de Windows Vista” de Microsoft Research

En 2008, Nagappan y otros de Microsoft Research realizaron un estudio cuantitativo a gran escala sobre el proyecto Windows Vista. Buscaban responder una pregunta clave: ¿qué factor predice con mayor precisión los defectos (bugs) en el software?

Las candidatas incluían: complejidad del código, líneas de código, frecuencia de cambios, experiencia del desarrollador… y una variable que parecía ajena a lo “técnico”: distancia organizacional (es decir, la distancia jerárquica entre los equipos que desarrollan módulos relacionados).

Las conclusiones del estudio inquietan a muchos tecnócratas: la distancia organizacional predice con mayor precisión la tasa de defectos en software que la complejidad del código. En otras palabras, un módulo desarrollado por equipos que están “lejos” en el organigrama tiene más probabilidades de contener bugs que otro extremadamente complejo pero mantenido por un equipo con colaboración estrecha. Lo que crees que es un bug causado por un código mal escrito, podría ser en realidad un defecto de diseño organizacional.

Esta revelación tiene implicaciones empresariales mucho más profundas de lo que parece a primera vista: tu estrategia de QA debe seguir la estructura organizacional, no la complejidad del código. Los módulos desarrollados por equipos cruzados requieren una cobertura de pruebas más estricta y procesos de revisión más rigurosos, incluso si el código en sí parece sencillo. En la era actual, donde la generación de código por IA está en auge (Copilot ya produce el 46% del código escrito por usuarios), este principio se vuelve aún más crítico — exploraremos en detalle el caso de Coinbase en el artículo 8, cuando analicemos la “paradoja de la productividad”.

El “impulso” y la “preocupación oculta” del estudio DORA

El equipo DevOps Research and Assessment (DORA), propiedad de Google y liderado por Nicole Forsgren, Jez Humble y Gene Kim, publicó el estudio más amplio hasta la fecha sobre el rendimiento en la entrega de software.

El hallazgo central coincide profundamente con la Ley de Conway: “Si implementamos una arquitectura desacoplada y bien encapsulada, acompañada de una estructura organizacional alineada, podemos mejorar tanto el ritmo de entrega como la estabilidad, y mantener un crecimiento productivo lineal e incluso superlineal incluso cuando los equipos de ingeniería se expandan significativamente.” Sin embargo, el informe DORA de 2022 también descubrió un efecto secundario intrigante: aunque la arquitectura desacoplada mejora la eficiencia de entrega, puede aumentar el agotamiento de los equipos. La causa podría ser que, cuando los equipos son altamente autónomos y mutuamente aislados, los miembros pierden la percepción del propósito global, sintiéndose como “solo una pieza del engranaje”.

Este es un recordatorio importante: la alineación entre arquitectura y organización no es una bala de plata; resuelve problemas de eficiencia, pero puede generar problemas culturales. Una inferencia profundamente reflexiva: si una arquitectura desacoplada + organización desacoplada ya hace que los desarrolladores humanos se sientan aislados, ¿qué sucede cuando se incorporan agentes de IA al equipo? La IA no “siente aislamiento”, pero los humanos se volverán aún más aislados. Este aspecto rara vez se discute, pero en nuestros materiales de investigación, un informe de BCG de 2025 plantea el “dilema de coordinación de los gerentes intermedios”—el tema central de nuestra undécima publicación.

3. El “momento Conway” de tres empresas de billones de dólares

Amazon: un correo electrónico del CEO que lo cambió todo

Alrededor de 2002, Jeff Bezos emitió dentro de Amazon el famoso “API Mandate”: todos los equipos debían comunicarse exclusivamente a través de interfaces de servicio (API), prohibiéndose expresamente el acceso directo a los almacenes de datos de otros equipos.
Se dice que la última línea de ese correo decía: “Las personas que no cumplan con lo anterior serán despedidas”.
Muchos consideran la arquitectura de microservicios de Amazon una decisión técnica. Pero desde la perspectiva de la Ley de Conway, lo que Bezos hizo fue realmente una decisión de estructura organizacional: primero impuso mediante gestión el corte de las “vías rápidas” de comunicación entre equipos, y luego la arquitectura de software evolucionó naturalmente hacia módulos de servicios aislados.
Eso dio lugar al posterior concepto de Bezos de los “equipos de dos pizzas” (Two-Pizza Team): cada equipo no debía superar el número de personas que dos pizzas podrían alimentar (generalmente 5-8 personas), y cada equipo poseía su propio servicio, lo desplegaba de forma independiente y se comunicaba con el exterior únicamente mediante API.
El imperio de microservicios de Amazon no fue diseñado por arquitectos, sino que creció espontáneamente a partir de su estructura organizacional. Este es el ejemplo más clásico y positivo de la Ley de Conway.

Pero aquí hay un aspecto que muchos artículos no mencionan: el éxito del enfoque de Amazon no solo se debe a que Bezos entendió la Ley de Conway, sino también porque resolvió simultáneamente el problema del “alineamiento de incentivos”. Cada “equipo de dos pizzas” posee su propio estado de resultados (P&L); no solo son autónomos técnicamente, sino también comercialmente. Esto significa que los equipos tienen un incentivo intrínseco para mantener claros los límites de sus servicios: porque una frontera borrosa implica responsabilidad borrosa, y una responsabilidad borrosa implica evaluación borrosa. El triángulo alineado entre estructura organizacional + estructura de incentivos + arquitectura técnica es la imagen completa del modelo de Amazon. Las empresas que solo imitan la estructura organizacional sin aprender el diseño de incentivos suelen captar solo la forma, no la esencia.

Spotify: El modelo ideal frente a la “entropía” de la realidad

El modelo “Squad” de Spotify fue considerado en Silicon Valley como la biblia del diseño organizacional: pequeños equipos autónomos de 5 a 8 personas (Squads), varios Squads forman tribus (Tribes), expertos técnicos transversales forman capítulos (Chapters), y comunidades impulsadas por intereses forman guilds (Gremios).

El pensamiento detrás de este modelo es altamente coherente con la Ley de Conway: mediante una estructura de equipos pequeños y autónomos, se impulsa la creación de servicios de software pequeños y autónomos.

Pero Spotify más tarde también reconoció que la realidad es mucho más compleja que el modelo. Cuando el negocio crece hasta cierta escala, las dependencias entre equipos se vuelven inevitables, y la autonomía pura comienza a generar costos de coordinación. Esto revela una implicación a menudo ignorada de la Ley de Conway: la estructura organizacional no se diseña una vez y se resuelve para siempre; al igual que el software, tiene una tendencia al aumento de entropía. A medida que la complejidad del negocio crece, los límites organizacionales se vuelven borrosos, las rutas de comunicación se alargan y la arquitectura del sistema se degrada. Las organizaciones técnicas excelentes no “diseñaron una buena arquitectura”, sino que establecieron la capacidad de ajustar continuamente la alineación entre organización y arquitectura. Esta capacidad la exploraremos en el artículo 2 sobre Team Topologies — que ofrece un marco más sistemático y operativo que el modelo de Spotify. ## Apple: ¿Por qué Siri fue “derrotada” por ChatGPT?
En 2024-2025, el plan de actualización de IA de Siri de Apple se convirtió casi en un “contramodelo” de la Ley de Conway.

La raíz del problema no es técnica. Apple cuenta con talento de investigación en IA de primer nivel mundial y fondos abundantes. Pero el desarrollo de Siri involucra dos equipos con una grieta estructural en la organización: el equipo de investigación en IA (liderado por John Giannandrea) y el equipo de desarrollo de producto (liderado por Craig Federighi).

Ambos equipos tienen prioridades distintas, ritmos distintos y criterios de éxito distintos. El equipo de investigación busca avances fronterizos en la capacidad de los modelos; el equipo de producto busca entregas estables de experiencia de usuario. Cuando la estructura de comunicación entre estos dos “nodos” organizacionales es fragmentada, el sistema resultante inevitablemente también lo será.

¿Qué es Siri en manos del usuario final? Un “asistente mediocre de funciones ensambladas”: cada módulo parece aceptable por separado, pero integrado carece de una experiencia inteligente coherente. Esto es exactamente lo que la Ley de Conway predijo: las grietas en el sistema reflejan las grietas en la organización.

El caso de Apple merece especial atención de los tomadores de decisiones en empresas chinas. Muchas empresas están atravesando exactamente la misma dificultad: los equipos de IA y los equipos de negocio pertenecen a diferentes VP, y los proyectos de implementación de IA se convierten en “un juego político entre dos departamentos” en lugar de “una entrega colaborativa de un solo producto”.

Si tu empresa está impulsando la implementación de IA, echa un vistazo a tu organigrama: ¿la capacidad de IA existe como un departamento independiente o está incrustada dentro de los equipos de negocio? La respuesta a esta pregunta puede determinar el éxito o fracaso del proyecto más que la elección del modelo de IA que utilices.

Cuatro: La era de la IA: La ley de Conway está siendo reescrita

Cuando los “nodos organizacionales” ya no son todos humanos

En 2026, la ley de Conway enfrenta su desafío más profundo desde 1968. Cuando Conway formuló esta ley, asumía implícitamente que cada “nodo” dentro de una organización era humano: la estructura de comunicación era puramente entre personas.

Pero hoy, los agentes de IA están entrando en los organigramas. Claude Code puede completar tareas de desarrollo multi-paso de forma autónoma; el sistema Minions de Stripe genera más de 1.000 PR fusionados por semana; Cursor ha transformado por completo la forma en que trabajan los ingenieros de NVIDIA. Según Gartner, las consultas empresariales sobre orquestación multi-agente de IA aumentaron un 1445% en 2025.

¿Qué sucede con la ley de Conway cuando algunos nodos dentro de la organización ya no son humanos?

La discusión de este tema recorrerá la segunda mitad de toda nuestra serie: el fenómeno del “solitario unicornio” en el artículo 10, “La ley de Conway encuentra agentes de IA” en el artículo 11, y “Agentic Engineering” en el artículo 14—pero aquí ofrecemos tres juicios preliminares para ayudarte a construir un marco de pensamiento:

Primero, la estructura de comunicación se convertirá en estructura de estrategia. La comunicación entre humanos depende de la cultura, la intuición y las interacciones informales. Pero entre humanos y agentes de IA no existe “intuición”: debes definir los límites de la interacción mediante estrategias, reglas y permisos explícitos. La capacidad de gobernar reemplazará a la capacidad de comunicación como variable central en el diseño organizacional.

Segundo, los organigramas se convertirán en mapas de permisos. Los organigramas tradicionales describen relaciones de jerarquía y división de funciones. El “organigrama” de la era de la IA se asemeja más a un grafo dirigido acíclico (DAG), que define capacidades y restricciones: ¿qué agente puede acceder a qué datos, ejecutar qué operaciones y bajo qué condiciones requiere aprobación humana?

Tercero, el conocimiento institucional se trasladará de las personas a las estrategias. Antes, “cuando un empleado experimentado se iba, se llevaba el conocimiento” era el dolor de cada empresa. En el futuro, el conocimiento clave se codificará en las estrategias y contextos de los agentes de IA—esto es tanto una oportunidad (el conocimiento ya no se pierde) como un riesgo (un error en la estrategia puede amplificarse sistemáticamente).

Cada una de estas afirmaciones respalda una gran cantidad de prácticas industriales y datos. Por ejemplo, el tercer punto sobre “transferencia de conocimiento institucional” ofrece un ejemplo conmovedor, tanto positivo como negativo, basado en el caso de Klarna: tras despedir al 40 % de su personal, descubrieron que su sistema de IA no podía reemplazar el conocimiento tácito que los empleados se llevaron consigo, lo que los obligó a contratar nuevamente. Esta historia la desarrollaremos por completo en el artículo 9, “La lección de Klarna”.

La primera y segunda afirmaciones no son solo nuestras. En el podcast de a16z de julio de 2026, “Software in the Age of Agents”, Seema Amble, socia del equipo corporativo de a16z, y Steven Sinofsky, expresidente de Windows en Microsoft, llegaron a conclusiones altamente alineadas desde su observación directa en inversiones. Steven resumió el núcleo de la afirmación uno en una frase: “El mayor efecto de red en el software empresarial está dentro de una empresa” (The biggest network effect in enterprise software is inside of a company): la red compuesta por relaciones humanas, procesos y sistemas dentro de la organización es lo que realmente genera fidelidad. Los agentes no pueden acceder a esta red por “entendimiento implícito”; solo pueden hacerlo mediante estrategias y permisos explícitos — esta es precisamente la presión real que convierte la estructura de comunicación en una estructura de estrategia. Seema, por su parte, corroboró la afirmación dos desde la perspectiva del acceso de los agentes a los sistemas empresariales: cuando un agente debe “ejecutar” (escribir registros en el sistema, modificar contabilidad), de inmediato se topa con todo un conjunto de problemas: identidad, credenciales, licencias de facturación, permisos de aprobación. El organigrama está siendo reescrito como un mapa de permisos: “¿Quién puede acceder a qué, y quién autoriza qué?”. Estas dos afirmaciones no son predicciones; son cosas que ya están sucediendo en los proyectos en los que los inversores en primera línea están apostando actualmente. (Invitados: socios de a16z / exejecutivos de Microsoft, postura de VC.)

Cinco: ¿Qué tipo de “error de Conway” está cometiendo tu organización?

Si llegaste hasta aquí y aún piensas “ya entiendo todos estos conceptos”, te invito a hacer un ejercicio.

A continuación, presentamos cinco patrones comunes de desalineación entre organización y arquitectura, derivados de la Ley de Conway y sus extensiones. Revisa tu propia empresa y verifica cuántos de estos puntos aplican:

❶ Microservicios superficiales: El código se dividió, pero 50 personas siguen discutiendo en el mismo grupo de chat.
❷ Ilusión de la plataforma central: La plataforma central se convirtió en el cuello de botella de comunicación para todas las líneas de negocio.
❸ Islas de IA: Los modelos desarrollados por el equipo de IA no pueden integrarse en los productos, porque organizativamente “no van por el mismo camino”.
❹ Degradación de la colaboración remota: La separación física generó fragmentación innecesaria en los sistemas.
❺ Mala digestión de adquisiciones: La incompatibilidad cultural organizacional provocó el fracaso en la integración técnica.

Próximos pasos

Esta es la primera de 15 publicaciones de la serie “La transformación de la ingeniería de software en la era de la IA”. Partimos de la Ley de Conway para establecer una认知 básica: la arquitectura organizacional determina la arquitectura del sistema; esto no es una metáfora, sino una relación causal verificada empíricamente.

Pero conocer esta ley es solo el punto de partida. La pregunta verdadera es: ¿Podemos invertirla? Diseñar intencionalmente la estructura organizacional para guiar la arquitectura del sistema deseado: esta es la idea central del “Maniobra de Conway Inversa” (Inverse Conway Maneuver).

En el próximo artículo, “Team Topologies — Una metodología de diseño organizacional en la era post-Agile”, exploraremos cómo Matthew Skelton y Manuel Pais transformaron esta idea en un marco completo y operativo, incluyendo cuatro tipos básicos de equipos, tres patrones de interacción y el concepto de “carga cognitiva”, ampliamente subestimado. Casos de práctica de empresas como Netflix, Adidas y Accenture demostrarán: ¿en qué condiciones funciona la Maniobra de Conway Inversa, y en cuáles fracasa?

Nota de la serie: Esta serie seguirá de cerca la evolución más reciente de las herramientas de programación con IA, las arquitecturas organizacionales y los paradigmas de ingeniería de software, como los nuevos cambios de la Ley de Conway en la era de los agentes de IA en 2026, o la madurez del ecosistema de herramientas más reciente. Suscríbete a la serie para obtener insights actualizados continuamente.

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 tomadores de decisiones tecnológicos en empresas, compuesta por 15 artículos. Basada en un estudio sistemático de más de 200 artículos académicos e informes industriales, te ofrece referencias decisionales con etiquetas de nivel de evidencia. Espera más contenido.

Fuentes de referencia:

Conway, M. (1968). How Do Committees Invent? Datamation, 14 (4), 28-31.
Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
MacCormack, A., et al. (2012). Exploring the Duality between Product and Organizational Architectures: A Comparative Study of Commercial and Open Source Software. Harvard Business School Working Paper.
Nagappan, N., et al. (2008). The Influence of Organizational Structure on Software Quality. ICSE ‘08 Proceedings.
Forsgren, N., et al. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
Fowler, M. (2022). Conway’s Law. Martinfowler.com/bliki/ConwaysLaw.html.
Gartner (2025/26). Predicts 2026: AI Agents in Software Engineering.
a16z (2026). Software in the Age of Agents. The a16z Podcast. (Steven: “El mayor efecto de red en el software empresarial está dentro de una empresa” + Seema Amble sobre cómo los agentes se encuentran con permisos/credenciales/ubicaciones de facturación al acceder a sistemas empresariales, que sustentan las afirmaciones 1 y 2 de la sección 4; fuente primaria: audio original del podcast. Etiqueta de postura: Socia de a16z / exdirectora ejecutiva de Microsoft. Invitados verificados: Seema Amble, socia del equipo empresarial de a16z; Steven Sinofsky, expresidente de Windows de Microsoft (board partner); Elena Burger, redactora de a16z; emitido en julio de 2026.)