El organigrama es un mapa de deuda técnica.

Entre enero y julio de 2026 se registraron 1.307 operaciones de fusiones y adquisiciones en América Latina por USD 60.159 millones, según TTR Data. Brasil concentró 744, Chile 189 y México 153. El número de transacciones cayó 26% interanual y el capital movilizado apenas 4%: menos operaciones, más grandes.

Cada una de esas 1.307 operaciones tiene una consecuencia que no figura en el modelo financiero. Al día siguiente del cierre, la compañía compradora tiene dos sistemas de identidad, dos maestros de clientes, dos formas de calcular el mismo indicador y, en el mejor de los casos, un plan de integración de dieciocho meses que nadie va a terminar.

El trabajo más citado es el de Alan MacCormack, John Rusnak y Carliss Baldwin, de Harvard Business School, sobre lo que llamaron la hipótesis del espejo.

Eso no es un problema de tecnología. Es un problema de organigrama que se manifiesta en tecnología. Y es la principal fuente de deuda técnica que las empresas de la región no contabilizan, porque la asignan a la línea equivocada del presupuesto.

Conway no escribió una metáfora. Escribió una restricción de diseño.

En 1967, Melvin Conway formuló la idea que después se conoció como su ley y la publicó en abril de 1968 en Datamation, en un artículo titulado "How Do Committees Invent?". La formulación original es más dura que la versión de póster: las organizaciones que diseñan sistemas están restringidas a producir diseños que son copias de las estructuras de comunicación de esas organizaciones.

La palabra importante es "restringidas". Conway no dijo que los sistemas tienden a parecerse al organigrama. Dijo que no pueden no parecerse. Si dos equipos no se hablan, la interfaz entre sus componentes va a ser mala, sin importar cuán buenos sean los ingenieros de cada lado. El límite no es de talento. Es de ancho de banda de comunicación.

La evidencia empírica llegó mucho después. El trabajo más citado es el de Alan MacCormack, John Rusnak y Carliss Baldwin, de Harvard Business School, sobre lo que llamaron la hipótesis del espejo. Compararon pares de productos de software con funcionalidad equivalente pero desarrollados por organizaciones de estructura distinta, y encontraron soporte fuerte para la hipótesis: los equipos más grandes y distribuidos producen arquitecturas más modulares. La magnitud no fue marginal; en los pares analizados, las diferencias de modularidad llegaron a variar por un factor de ocho.

Hay más. Investigadores de Microsoft junto a la Universidad de Maryland —Nagappan, Murphy y Basili— produjeron estudios de caso que apuntan en la misma dirección, y trabajos posteriores en la Universidad Tecnológica de Tampere replicaron el patrón.

La conclusión práctica es incómoda para cualquier CTO regional: si tu arquitectura te molesta, el problema probablemente no esté en el repositorio.

La reorganización es una decisión de arquitectura tomada por gente que no la ve.

Acá está el punto que la región no discute. Una reorganización parece un movimiento de personas. En realidad es un movimiento de fronteras de comunicación. Y las fronteras de comunicación son las junturas del sistema.

El patrón es siempre el mismo. Un equipo de plataforma se parte en dos porque dos directores necesitaban un equipo cada uno. Seis meses después hay dos servicios que hacen casi lo mismo, porque cada mitad resolvió su necesidad sin coordinar con la otra. Un año después, alguien propone consolidarlos y el proyecto se estima en un trimestre. Nunca dura un trimestre.

O al revés: dos equipos se fusionan por reducción de costos, pero los sistemas siguen separados, y ahora un solo equipo mantiene dos arquitecturas que fueron pensadas con supuestos incompatibles. La carga cognitiva de ese equipo se duplicó sin que ninguna métrica lo registre. Lo que se registra, meses más tarde, es el aumento de incidentes y la renuncia de las dos personas que entendían el sistema viejo.

Nada de esto aparece en el business case de la reorganización. El business case habla de spans de control, de niveles jerárquicos y de ahorro de headcount. No hay una línea que diga: "esta decisión crea tres integraciones nuevas y las va a mantener alguien que todavía no contratamos".

La deuda técnica no es un problema de ingeniería. Es un problema de presupuesto.

Los números disponibles ubican la magnitud. Según el análisis del Deloitte Center for Integrated Research publicado el 27 de marzo de 2026, la deuda técnica representa entre 21% y 40% del gasto en tecnología de una organización, con un punto medio de 30%, con base en su estudio global de liderazgo tecnológico 2026. Casi 60% de los líderes consultados cree que entre 21% y 50% del valor de sus inversiones en tecnología, datos y personas está atrapado sin materializarse. El mismo trabajo modela que la modernización de infraestructura, por sí sola, reduce la deuda técnica en 18% en cinco años.

Traducido a una conversación de directorio: entre un quinto y dos quintos de lo que gastás en tecnología no compra capacidad nueva. Paga decisiones organizacionales viejas.

Y ahí está el error de atribución. Cuando ese porcentaje aparece en el reporte, se discute con el CTO. Se le pide un plan de reducción de deuda técnica, un refactor, una migración. Pero el CTO no generó la deuda. La generaron las reorganizaciones, las adquisiciones y los cambios de estrategia comercial que partieron y volvieron a unir equipos sin que nadie mirara el costo de las junturas.

Pedirle al área de ingeniería que resuelva sola la deuda técnica es como pedirle al área de mantenimiento que resuelva el diseño de la planta.

La plataforma interna es un contrato organizacional disfrazado de herramienta.

El reporte DORA 2025, publicado el 23 de septiembre de 2025 por Google Cloud sobre casi 5.000 profesionales de tecnología, trae dos datos que conviene leer juntos.

El primero: 90% de las organizaciones ya tiene alguna forma de plataforma interna y 76% tiene equipos dedicados de plataforma. Eso dejó de ser una práctica de vanguardia. Es la norma.

El segundo: 90% de los encuestados usa inteligencia artificial en el trabajo y más del 80% cree que le aumentó la productividad, pero un 30% declara poca o nula confianza en el código que la IA genera. La adopción de IA se asocia positivamente con el throughput de entrega y con el desempeño del producto, y negativamente con la estabilidad de la entrega. La frase con la que el propio reporte resume el hallazgo es la que interesa: la IA no arregla a un equipo, amplifica lo que ya está ahí.

La conexión con Conway es directa. Una plataforma interna de calidad es, en el fondo, una interfaz explícita entre equipos: define qué se puede pedir, cómo, y quién responde. Es el único mecanismo conocido para desacoplar la arquitectura del organigrama, porque reemplaza la coordinación humana ad hoc por un contrato estable que sobrevive a la reorganización.

Sin esa capa, cada cambio de organigrama se traduce en un cambio de arquitectura. Con esa capa, el organigrama puede moverse sin que el sistema se parta. Ese es el argumento de negocio para invertir en plataforma, y no tiene nada que ver con la productividad del desarrollador individual.

Crecer por adquisición es comprar organigramas ajenos.

Las compañías regionales que crecieron comprando —bancos que compraron fintechs, retailers que compraron operadores logísticos, grupos que consolidaron competidores país por país— tienen una versión agravada del problema.

No heredaron sistemas. Heredaron las estructuras de comunicación de otras empresas, congeladas en código. El maestro de clientes de la empresa comprada refleja cómo esa empresa dividía sus áreas comerciales. Su sistema de facturación refleja cómo negociaba sus contratos. Su modelo de datos refleja qué preguntas hacía su directorio.

Integrar eso no es un proyecto técnico. Es imponer un organigrama sobre otro, con la diferencia de que el organigrama perdedor está escrito en producción y factura todos los meses.

Por eso los planes de integración post-fusión de la región fallan con tanta consistencia. Se presupuestan como migraciones y se ejecutan como negociaciones políticas. La estimación de dieciocho meses supone un problema de ingeniería. El problema real es que hay dos directores que no quieren perder su modelo de datos, y ninguno de los dos va a decir eso en la reunión.

Con 1.307 operaciones en siete meses solo en América Latina, y con Brasil concentrando más de la mitad, esto no es un caso de borde. Es el modo dominante de crecimiento corporativo de la región y viene con una factura técnica que nadie está reservando.

Cómo se ve la ley de Conway en tu propia empresa, sin teoría.

El diagnóstico se puede hacer en una tarde y no necesita una consultora.

Tomá el diagrama de arquitectura de tus sistemas críticos y poné al lado el organigrama de tecnología de hace tres años. No el de hoy: el de hace tres años, porque los sistemas tienen la forma de la organización que los escribió, no de la que los mantiene. Si los bloques coinciden, ya sabés de dónde salió la arquitectura.

Después buscá tres señales concretas. La primera: componentes que hacen casi lo mismo y conviven. Casi siempre corresponden a dos áreas que en algún momento reportaron a jefes distintos. La segunda: integraciones sin dueño declarado, esas donde la respuesta a "¿quién la mantiene?" es un nombre propio y no un equipo. Suelen ser junturas entre áreas que se reorganizaron y nadie reasignó. La tercera: procesos donde un cambio simple necesita coordinación de tres o más equipos. Cada uno de esos procesos es una frontera organizacional atravesando un flujo de negocio.

Con esas tres listas en la mano, la conversación cambia de tono. Deja de ser "necesitamos refactorizar" —que en un directorio suena a capricho de ingeniería— y pasa a ser "tenemos catorce integraciones sin dueño, y once de ellas se crearon en las últimas tres reorganizaciones". Eso es un argumento de gestión, con causa identificable y responsable identificable.

También sirve para lo contrario: para frenar reorganizaciones. Cuando alguien propone partir un equipo, la pregunta correcta no es cuántas personas quedan de cada lado. Es qué componentes quedan a cada lado de la nueva frontera y qué pasa con los que estaban en el medio.

El contraargumento honesto.

Hay tres objeciones legítimas.

La primera es metodológica. Los estudios que sostienen la hipótesis del espejo se apoyan en buena medida en software de código abierto y en comparaciones donde es difícil separar causa de efecto: puede que la arquitectura elegida haya determinado cómo se organizaron los equipos, y no al revés. La correlación entre estructura organizacional y estructura de sistemas está bien documentada; la dirección de la flecha, menos.

La segunda es que la ley de Conway es descriptiva, no determinista. Equipos con disciplina de diseño, revisión de arquitectura y buena documentación producen sistemas mejores que su organigrama. La restricción existe, pero no es un techo de hormigón.

La tercera apunta al remedio de moda. La llamada maniobra inversa de Conway —reorganizar los equipos para obtener la arquitectura deseada— se volvió una consigna repetida sin costo. En la práctica, reorganizar personas para forzar una arquitectura suele producir una arquitectura que la organización no sabe operar, con más servicios de los que puede monitorear y más equipos de los que puede coordinar. La estructura de equipos y la carga cognitiva importan; usar la reorganización como herramienta de diseño técnico es tan riesgoso como ignorarla.

Las tres son válidas. Y las tres siguen sin explicar por qué, de manera tan repetida, dos empresas con presupuestos parecidos y gente parecida terminan con arquitecturas de calidad tan distinta. La variable que mejor separa esos dos casos no es la calidad promedio de los ingenieros. Es la cantidad de veces que se movieron las fronteras internas sin pagar el costo de reconstruir las interfaces.

Consecuencia operativa.

Metan la arquitectura en el proceso de decisión organizacional, no después.

En concreto: ninguna reorganización que parta o fusione equipos de tecnología debería aprobarse sin un documento de una página que responda tres preguntas. Qué interfaces nuevas crea esta decisión. Quién es el dueño de cada una a partir del día uno. Qué componentes quedan sin dueño claro.

En adquisiciones, el equivalente es una línea explícita en el modelo: costo de integración de sistemas, con supuesto de qué modelo de datos sobrevive y quién lo decide, definido antes del cierre y no seis meses después. Si esa decisión no está tomada al firmar, el plazo de integración que figura en el memo es ficción.

Y para el reporte anual de tecnología, un cambio de encabezado. La deuda técnica deja de reportarse como un problema del área de ingeniería y pasa a reportarse junto a las decisiones que la generaron: cuántas reorganizaciones hubo, cuántas adquisiciones se integraron, cuántos equipos cambiaron de dueño. Con esa tabla al lado, la conversación deja de ser sobre refactorizar y empieza a ser sobre cuánto cuesta, en sistemas, la costumbre de mover cajitas.