Voy a decir algo que debería ser obvio pero que la industria se niega a aceptar: no puedes arreglar tu arquitectura técnica sin meter las manos en tu organigrama.

Puedes contratar a los mejores ingenieros del mercado, adoptar la última tecnología de moda, hacer refactors épicos y migrar a microservicios con toda la fe del mundo. Si tu organización está rota, tu software va a estar roto. Es así de simple.

Melvin Conway lo escribió en 1967. Casi sesenta años después, seguimos cayendo en la misma trampa.

La Radiografía Más Honesta que Existe

Cuando llego a una organización nueva y quiero entender cómo funciona de verdad, no miro el PPT del all-hands. No pido el organigrama oficial. No agenda reuniones con cada gerente.

Miro la arquitectura del software.

Los repositorios, los servicios, las dependencias reales. Quién llama a quién. Dónde están los cuellos de botella. Qué módulo tiene dueño claro y cuál es tierra de nadie.

Eso te dice más sobre la organización que cualquier diagrama oficial. Te dice quién tiene poder, quién no habla con quién, dónde están los conflictos no resueltos y qué equipo opera como isla.

El codebase no miente, no embellece, no tiene agenda política. Es un espejo brutal de quién habla con quién en tu empresa.

Y Conway lo formalizó así:

“Las organizaciones que diseñan sistemas están constreñidas a producir diseños que son copias de las estructuras de comunicación de esas organizaciones.”

Traducido al chileno: si tienes tres gerencias que no conversan, tu producto va a tener tres módulos que tampoco conversan. Con APIs internas que parecen tratados de paz entre naciones en conflicto. Y un middleware que existe solo porque alguien necesitaba un puente entre dos feudos que se rehúsan a compartir una base de datos.

No es una metáfora. Es un diagnóstico.

El Refactor que No Sirve de Nada

El error clásico: detectan que la arquitectura es un desastre, contratan un Staff Engineer, le dan carta blanca para “arreglar la arquitectura”. El tipo hace un diagrama bkn hermoso, propone una migración a event-driven, diseña dominios limpios con bounded contexts perfectos.

Seis meses después, la arquitectura nueva es un reflejo exacto de la vieja. Solo que ahora tiene Kafka en el medio.

No importa cuántas veces rediseñes el sistema. Si los mismos silos siguen existiendo, los mismos silos van a reaparecer en el código. Como pintar encima de una pared con humedad. Queda bonito dos semanas.

El refactor que realmente necesitas no está en el codebase. Está en la estructura de tus equipos.

La Jugada Inteligente: Diseñar el Organigrama Primero

Si la Ley de Conway es inevitable, la única jugada inteligente es usarla a tu favor. Diseñas tus equipos para que produzcan la arquitectura que necesitas, no al revés.

En Lemontech llegué a una organización con tres equipos pequeños, cada uno dueño de su pedazo de dos productos legacy que nadie quería tocar. La arquitectura era exactamente lo que esperabas: módulos que no conversaban, lógica duplicada por todos lados, y un deployment que dependía de que los tres equipos estuvieran alineados al mismo tiempo. Que nunca lo estaban.

No empecé por el código. Empecé por el organigrama.

Formamos pilares organizados por unidad de negocio, no por tecnología. Cada pilar era dueño de su dominio completo, de la interfaz a la base de datos. Sin equipos de “frontend” o “backend” flotantes que dependían de que alguien más completara su parte. Si el pilar de Facturación necesitaba un cambio, el pilar de Facturación lo hacía y lo desplegaba. Solo.

El código que empezaron a producir esos equipos era radicalmente distinto al de antes, y nadie les pidió que lo fuera. No hubo un documento de arquitectura nuevo. No hubo un Staff Engineer que les dictara cómo organizarse. La estructura de comunicación cambió, y el software simplemente la reflejó.

Más tarde descubrí que ese principio tenía nombre formal: Team Topologies. Los autores llevan años diciéndolo en inglés con diagramas elegantes. Yo llegué a la misma conclusión a los golpes, en producción, con equipos reales.

El Verdadero Spaghetti

La industria está obsesionada con el spaghetti code. Hacemos code reviews, aplicamos SOLID, compramos herramientas de análisis estático. Pero nadie contrata un consultor para mirar el organigrama y decir: “oigan, esto es spaghetti organizacional y es la razón por la que su software parece un castillo de naipes”.

El código desordenado se arregla con un buen refactor. La organización desordenada se arregla con decisiones que a nadie le gusta tomar: mover personas, cambiar líneas de reporte, fusionar equipos, eliminar capas de gestión que solo agregan latencia.

Lo sé porque lo hice. Y fue mucho más difícil que cualquier migración técnica que haya liderado. Pero el software que salió al otro lado no se parecía en nada al de antes.

El spaghetti más peligroso no está en tu repositorio. Está en tu organigrama.