¿Has oído eso de que los perros se parecen a sus dueños?
Fíjate en algún amigo o vecino y verás que algo de cierto hay: la forma de andar, la mirada, incluso la actitud.
Lo mismo pasa con las personas que conviven mucho tiempo. Ya lo dice el refrán: “quien comparte colchón, se vuelve de la misma condición”. Y ese otro clásico: “todo se pega, menos la hermosura”.
Pues bien, en las organizaciones ocurre exactamente lo mismo.
Piensa en las empresas en las que has trabajado. ¿Cuántas? ¿Cómo eran las personas? ¿Qué cultura respiraba el día a día? Y, sobre todo, ¿cómo te influyó a ti?
Con el tiempo, uno acaba mimetizándose sin darse cuenta. Como una vacuna invisible que te cambia el sistema inmunitario: un día te descubres defendiendo con uñas y dientes algo que, años antes, te habría parecido ajeno o absurdo.
A mí me ha pasado varias veces. Y sospecho que no soy el único.
Ahí es donde entra en juego la Ley de Conway.
“Cualquier organización que diseñe un sistema producirá un diseño cuya estructura es una copia de la estructura de comunicación de la organización.”
— Melvin Conway, 1967
Dicho de otra forma: construimos como hablamos.
Si los equipos no se comunican entre sí, los productos acaban siendo un puzzle de piezas que no encajan.
Si todo pasa por un único líder, el sistema será centralizado y rígido.
Si los equipos son autónomos y multidisciplinares, el resultado será modular, ágil, adaptable.
Lo fascinante es que esta ley nacida en el empresas del mundillo del desarrollo de software, hoy se podría aplica a cualquier tipo de organización: empresas, gobiernos, startups o incluso familias.
Lo que construyes refleja cómo trabajas.
Netflix es un ejemplo clásico.
La empresa organizó su estructura en equipos pequeños y autónomos, cada uno responsable de una parte del producto. El resultado fue una arquitectura basada en microservicios, donde cada componente es independiente y escalable.
Su cultura de libertad y responsabilidad no solo impulsó su tecnología, también su innovación constante.
Amazon entendió esto pronto.
Jeff Bezos instauró la “Regla de las dos pizzas”: ningún equipo debe ser tan grande que no puedan alimentarse con dos pizzas.
De esa filosofía nació AWS: cientos de equipos pequeños, cada uno dueño de su propio servicio. El tamaño importa… pero en este caso, cuanto más pequeño, mejor comunica.
Microsoft, en cambio, aprendió la lección por las malas.
Cuando lanzaron Windows Vista, un estudio interno reveló que las métricas organizativas —no las técnicas— eran los mejores predictores de los fallos del producto. Equipos enormes, comunicación cruzada y burocracia habían creado un monstruo incoherente.
Y Spotify convirtió el concepto en bandera.
Su modelo de Squads, Tribes y Guilds favorece la comunicación horizontal y el intercambio de conocimiento. El resultado: un producto con coherencia global y evolución continua.
Cuando la estructura impide el cambio
En el sector público, la Ley de Conway se vuelve una trampa.
Las administraciones están divididas por departamentos, presupuestos y jerarquías legales difíciles de modificar. El resultado: servicios digitales fragmentados, formularios duplicados, reglas contradictorias.
A diferencia de una empresa, un gobierno no puede “reorganizar su arquitectura” con facilidad. Cambiar el sistema requiere cambiar la estructura… y eso suele ser lo más difícil.
Pero, qué dice la ciencia en torno a esta ley empírica.
Estudios del MIT y Harvard Business School lo confirmaron:
los productos desarrollados por organizaciones débilmente acopladas tienden a ser más modulares, mientras que los de estructuras cerradas y jerárquicas son más monolíticos.
En resumen: la arquitectura técnica refleja la arquitectura humana.
Así que la próxima vez que algo no funcione…
No mires solo el código, los procesos o los KPIs.
Mira las conversaciones.
Mira quién habla con quién, y quién no.
Porque al final, toda innovación es una consecuencia directa de cómo nos organizamos para pensar, crear y decidir juntos.
Que nunca te falten ideas, ni ganas de probarlas.
A.
PD1: Si quieres leer más sobre el tema, te recomiendo The Mythical Man-Month de Fred Brooks, donde se popularizó la Ley de Conway, y Team Topologies de Matthew Skelton, que explica cómo diseñar equipos para evitar los efectos negativos de esta ley.
PD2: Jennifer Pahlka (ex CIO de EE.UU.) tiene un artículo brillante sobre cómo esta ley afecta al gobierno digital: Conway’s Law at Government Scale.
PD3: Si tu producto parece caótico… quizás tu organigrama también lo sea. Empieza por ahí.