🎖️La ley de Conway
Por qué la estructura de tu equipo importa
Hola 👋 bienvenido a la Newsletter de 🎖️ Team Hackers
Soy Felipe Polo y escribo esta newsletter para ayudar a fundadores y operadores de compañías a generar autonomía y equipos más fuertes.
¿Sabías que lo que entregas al cliente —producto, servicio o experiencia—no solo refleja el talento de tu equipo… sino también sus cuellos de botella, silos y chats de Slack?
Welcome to the world of Conway.
“Las organizaciones que diseñan sistemas tienden a producir diseños que reflejan sus estructuras de comunicación.”
— Melvin Conway, 1967
¿Qué significa esto en cristiano?
Si tu empresa está dividida en áreas que apenas se hablan… no te sorprendas si lo que entregas al cliente también está desalineado.
Los sistemas imitan las conversaciones (y la ausencia de ellas).
En esta edición vas a ver:
Cómo tu estructura organizativa se filtra en la experiencia del cliente, te guste o no.
Qué tienen en común tus cuellos de botella operativos con tus silos de comunicación.
Una maniobra estratégica que te permite rediseñar equipos para alinear negocio y realidad.
Y todo, gracias a una especie de karma organizacional que deja huella en todo lo que entregas.
🔬 El “experimento” de Conway
Un equipo de 8 personas debía crear dos compiladores, uno para COBOL y otro para ALGOL.
¿Cómo se distribuyó?
5 personas para COBOL.
3 personas para ALGOL.
¿El resultado?
El compilador COBOL terminó teniendo 5 fases.
El de ALGOL, 3 fases.
👀 Casualidad o no, el número de fases coincidía con el número de personas en cada equipo. El diseño técnico había imitado la estructura humana.
Lo dicho:
“Las organizaciones que diseñan sistemas tienden a producir diseños que reflejan sus estructuras de comunicación.”
Conway no la llamó ley. Ni pretendía que fuera una ley matemática. Él la planteó como una observación sociológica, un adagio del mundo del desarrollo técnico.
De hecho, su artículo fue rechazado al principio por falta de evidencia formal.
Desde entonces, el concepto ha viajado del software a los negocios, de la ingeniería militar a las startups como una advertencia persistente: tus sistemas van a parecerse a tus equipos, lo quieras o no.
Parece frase New Age, pero tiene más de física que de mística: "Los sistemas terminan pareciéndose a las empresas que los construyen.”
Ejemplos reales de la ley de Conway
1. Sitios web corporativos que se parecen al organigrama
Nigel Bevan (1999) analizó sitios web de grandes empresas y encontró que su estructura no respondía a la lógica del usuario, sino a la estructura interna de la compañía.
Menú de “Productos”, separado de “Soluciones”, separado de “Consultoría”... porque así están organizados los equipos.
Lo que debería ser una experiencia fluida para el usuario termina siendo un mapa político de la empresa.
2. Software abierto vs software cerrado
Un estudio de MacCormack et al. (2008) comparó productos equivalentes desarrollados por:
Equipos distribuidos de código abierto.
Equipos corporativos más centralizados.
¿Resultado? Los proyectos open source mostraron arquitecturas mucho más modulares. Hasta 8 veces menos acoplamiento.
Equipos más independientes → software más desacoplado.
3. Etsy y el efecto boomerang de Sprouter
Etsy tenía dos equipos:
uno para la aplicación web.
otro para las bases de datos.
El sistema terminó con dos capas lógicas, como era de esperarse.
Para facilitar la comunicación, crearon una tercera capa intermedia: Sprouter. Pero eso trajo un nuevo equipo, y entonces... tres capas de lógica y un infierno para cada despliegue.
El sistema se volvió frágil, lento, y difícil de mantener.
¿La solución? Unificar los equipos y simplificar la arquitectura.
DE OBSERVACIÓN CASUAL A MANUAL DE SUPERVIVENCIA TECNOLÓGICA
Después de que Melvin Conway publicara su artículo en 1968, la idea empezó a circular como un buen chisme técnico: incómodo, revelador y cada vez más difícil de ignorar.
🧠 1975 – Fred Brooks la bautiza
En su libro The Mythical Man-Month, Fred Brooks le pone nombre: la Ley de Conway.
Y con eso, la idea se vuelve oficial. Ya no se trata solo de compiladores.
📐1979 – Yourdon & Constantine le dan forma matemática
“La estructura de cualquier sistema diseñado por una organización es isomorfa a la estructura de esa organización.”
2004 – Coplien & Harrison nos enseñas a darle aplicación práctica
¡Alinea equipos y producto!
“Si la organización no refleja las partes esenciales del producto, el proyecto sufrirá.”
La recomendación es directa: “Asegúrese de que la organización es compatible con la arquitectura del producto.”
2010s en adelante – Nace la Inverse Conway Maneuver
Con la adopción de microservicios, prácticas DevOps y metodologías ágiles, surge un nuevo enfoque:
¿Y si organizamos los equipos según la arquitectura que queremos construir?
Eso es la maniobra Conway inversa (Inverse Conway Maneuver), promovida por referentes como Martin Fowler y Gene Kim.
🎯 La idea: En lugar de que los equipos se adapten al sistema, reorganiza los equipos para que el sistema refleje esa estructura deseada.
Ejemplo: Spotify implementó equipos multifuncionales llamados “squads”, cada uno encargado de una funcionalidad completa del producto.
¿El resultado?
Sistemas más coherentes, más fáciles de mantener y alineados con los flujos reales de trabajo.
¿Y ahora qué? Cómo usar la Ley de Conway a tu favor
Ya sabemos que los productos y sistemas tienden a parecerse a las estructuras de las organizaciones que los crean. En lugar de luchar contra esa realidad, la clave está en usarla estratégicamente.
Aquí algunos principios para aplicar la Ley de Conway a favor en cualquier producto o servicio que dependa de equipos humanos:
1. Diseña la estructura del equipo como parte del diseño del producto
Antes de pensar en funcionalidades, flujos, canales o servicios, pregúntate:
¿Quiénes trabajan en esto?
¿Cómo colaboran entre sí?
¿Quién toma decisiones, y en qué punto del proceso?
2. Aplica la maniobra Conway inversa (con criterio)
Agrupa personas por problemas a resolver, no por departamentos tradicionales.
Asegura que cada equipo tenga responsabilidad completa sobre su parte del sistema.
Alinea metas compartidas entre áreas que deban colaborar.
El diseño organizativo debe anticipar el producto deseado, no solo reflejar el actual.
3. Reduce silos antes de que se conviertan en fricciones visibles
Si hay equipos aislados, el cliente lo va a notar: en la experiencia, en el tiempo de respuesta, en la inconsistencia del producto o servicio.
4. Mide tu organización en términos de flujos reales, no de organigramas
La estructura formal rara vez refleja cómo fluye el trabajo de verdad.
Usa herramientas como mapeo de procesos, entrevistas internas o análisis de dependencias para detectar qué partes del producto sufren por falta de conexión humana.
5. Acepta que producto y organización evolucionan juntos
Donde el producto no fluye, es probable que la organización tampoco.
En resumen:
Cada decisión organizativa deja una huella en el producto o servicio.
No diseñas solo soluciones. Diseñas estructuras humanas que las hacen posibles.
Usa la Ley de Conway como guía para alinear personas, conversaciones y decisiones con el tipo de producto que realmente quieres construir.
Dónde más me puedes encontrar
En Linkedin escribo sobre liderazgo y gestión de equipos autónomos.
En Playbooks nos sentamos mensualmente con referentes empresariales que nos descubren sus estrategias paso a paso para que las puedas replicar en tu equipo.
En Escalando Agencias nos sentamos con fundadores de consultoras y agencias del sector digital para destripar cómo gestionan su crecimiento.
¡Hasta la próxima!
📘 De operador a diseñador de equipos autónomos
He creado para ti el minicurso “De Operador a Diseñador de equipos autónomos”, en el que explico por qué los equipos dependen demasiado de sus líderes (y cómo hacer que el tuyo funcione sin ti).
