Hay una frase atribuida a un conocido político argentino que dice:
"Si querés que algo no se haga, creá una comisión."
La Ley de Conway en acción
Más o menos en la misma época en que ese político estaba en el poder, Melvin E. Conway publicó su paper "How Do Committees Invent?". Ahí introdujo lo que hoy conocemos como la Ley de Conway:
"Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure."
¿Alguna vez viste una homepage sobrecargada que parecía más una lucha de poder entre departamentos que una experiencia amigable para el usuario?
Eso es la Ley de Conway en acción. Los equipos terminan entregando el organigrama.
Cómo la estructura de equipos impacta en la entrega de producto
¿Alguna vez viste equipos frenados esperando a otros equipos? ¿O servicios nombrados por su implementación interna en lugar del modelo de negocio al que sirven? Eso es la Ley de Conway en acción: tu producto termina siendo un espejo de los patrones de comunicación de tu organización.
Consciente o inconscientemente, las empresas diseñan sistemas que reflejan cómo se comunican internamente, o chocan contra una pared cuando intentan ir en contra de esos patrones.
El auge del trabajo remoto solo amplificó estos desafíos, haciendo que las estructuras claras de comunicación sean más críticas que nunca.
Muchas empresas intentan superponer frameworks "ágiles" sobre silos y jerarquías rígidas, pero ningún diseño de software puede arreglar estructuras organizacionales que introducen fricción y demoras.
Modernizar arquitecturas no es solo un esfuerzo técnico; requiere alinear la comunicación del equipo con los objetivos del producto. Por ejemplo, migrar a microservices no va a ayudar si tu equipo opera como una sola unidad grande.
Supongamos que contratás una agencia que te ofrece cuatro equipos de desarrolladores frontend y backend, y un DBA centralizado para manejar los cambios en la base de datos (esto viene de un ejemplo de Team Topologies):
Esta estructura va a llevar naturalmente a componentes separados de frontend y backend, y a una base de datos compartida:
Un DBA compartido fomenta una base de datos única, y separar los roles de frontend y backend lleva a capas separadas. Si tu objetivo es ownership descentralizado de los datos, esta estructura va a jugar en tu contra.
La Maniobra Inversa de Conway
Si tus equipos moldean tu arquitectura, ¿qué pasa cuando necesitás una arquitectura diferente? Acá es donde entra la Maniobra Inversa de Conway: en lugar de dejar que la estructura de los equipos dicte el diseño de tu software, reorganizás tus equipos para que coincidan con la arquitectura deseada.
Esta estrategia, destacada en el libro Accelerate, implica alinear tus equipos con la arquitectura que va a soportar entregas rápidas e independientes. Cuando tus equipos están organizados para minimizar dependencias y cuellos de botella, pueden desplegar más rápido y con menos problemas de coordinación.
Por ejemplo, si apuntás a microservices con ownership descentralizado de datos, los límites de los equipos deberían reflejar los límites de los servicios, con cada equipo siendo dueño de una porción del producto y sus datos. Una estructura de equipo cohesiva y autónoma reduce la necesidad de comunicación constante de alto ancho de banda, algo crucial para escalar sin fricción.
Sin embargo, esto no es fácil. No podés simplemente dividir equipos existentes y esperar que funcione. La mayoría de las startups no deberían empezar con microservices.
¿El camino más inteligente? Un monolito modular. Un solo deployment con límites internos bien definidos, donde los módulos son dueños de sus datos y se comunican a través de interfaces limpias. Todos los beneficios organizacionales de pensar en servicios, sin los dolores de cabeza de los sistemas distribuidos.
Cuando eventualmente necesites escalar una parte específica del sistema, esos límites de módulos se convierten en tus puntos de extracción. El Strangler Fig Pattern te permite desprender servicios gradualmente, pero solo cuando el dolor de mantenerlos juntos supera el costo de separarlos.
El objetivo no es solo técnico. Es crear estructuras de equipo que potencien la velocidad, la colaboración y el ownership, habilitando crecimiento e innovación a escala.
