Módulo 2: La Ley de Conway

4. El costo de coordinación

Siguiente →

Descripción

Al terminar esta lección vas a entender el motor económico que hace que la Ley de Conway tenga consecuencias tan caras, y por qué "haz equipos chicos" no es un consejo blando de manual de management sino una conclusión que sale de una fórmula. La fórmula es una de las más simples y más subestimadas del oficio: el número de canales de comunicación uno-a-uno entre n personas es n(n-1)/2. Lo que la hace importante no es la fórmula sino su forma: crece cuadráticamente, no linealmente. Duplicar el equipo no duplica la coordinación —la multiplica por cuatro—. Vas a ejecutar esta fórmula y ver el costo explotar: 2 personas necesitan 1 canal, 5 necesitan 10, 10 necesitan 45, y 50 personas necesitan 1225 canales de comunicación posibles. Ese crecimiento cuadrático es la razón matemática por la que un equipo grande se ahoga en su propia coordinación, y por la que partir la gente en equipos chicos —con la misma cantidad de personas— baja el costo de coordinación por un factor enorme.

Esto importa porque conecta las tres piezas del módulo en una sola cadena causal. Conway dice que el sistema copia la estructura de comunicación (lección 2). El monolito refleja el equipo único que lo parió (lección 3). Pero ¿por qué la organización no se queda simplemente como un equipo grande, evitando así todas las fronteras y su fricción? Porque la coordinación dentro de un equipo grande crece cuadráticamente hasta volverse insostenible, y en algún punto es más barato pagar el costo de las fronteras (dividir en equipos) que el costo de la coordinación interna (mantenerse como uno). La fórmula n(n-1)/2 es la que fija ese punto. Es también la que justifica por qué las team topologies (lección 7) insisten en equipos pequeños —del tamaño de "dos pizzas"—: no es una moda, es que arriba de cierto tamaño el costo de coordinación devora la capacidad de construir. Y es la que explica por qué la coordinación cross-team es el impuesto que Conway cobra: cada frontera que cruzas añade canales caros, y el arquitecto que entiende esta fórmula diseña para minimizarlos.

Conexión con el módulo: esta lección es el porqué cuantitativo. Las lecciones 2 y 3 mostraron que la organización moldea el sistema y que crecer sin partir en equipos desalinea; esta explica por qué crecer así es económicamente insostenible —la coordinación explota—. La fórmula que ejecutas aquí es la que da fuerza a todo lo que sigue: la fricción del módulo cruzado (lección 5) es cara porque cada par de equipos que debe coordinar es un canal costoso; la maniobra inversa (lección 6) vale la pena porque reduce los canales cross-team; y las team topologies (lección 7) prescriben equipos chicos porque n(n-1)/2 castiga a los grandes. Si la lección 3 dijo "el monolito de un equipo se rompe al partirse en cinco", esta dice "y no puedes evitarlo quedándote como un equipo gigante, porque eso cuesta todavía más".

La cena que se vuelve imposible de coordinar

Piénsalo así, con algo que todos hemos vivido. Quedas de cenar con un amigo. Coordinar es trivial: un mensaje, "¿a las 8 en el lugar de siempre?", "va", y listo. Un solo canal de comunicación, un solo acuerdo.

Ahora la cena es con cuatro amigos, cinco en total contigo. De repente hay que coordinar entre todos: tú con cada uno, y cada uno con los demás, porque alguien propone otro lugar, otro no puede a las 8, otro es vegetariano y hay que checar el menú. Los canales ya no son uno: entre cinco personas hay diez pares posibles que pueden estar poniéndose de acuerdo —tú-Ana, tú-Beto, tú-Carla, tú-Dani, Ana-Beto, Ana-Carla, y así—. La cena todavía se organiza, pero el grupo de WhatsApp ya tiene cien mensajes.

Ahora imagina la cena con cincuenta personas. Coordinar "por mensajes entre todos" es sencillamente imposible: hay 1225 pares que podrían estar discutiendo el lugar, la hora y el menú, y si dejas que todos hablen con todos, nunca se decide nada —el grupo se vuelve un caos de mil voces—. ¿Qué haces en la vida real cuando organizas un evento de cincuenta? No dejas que todos coordinen con todos. Nombras a un organizador, divides en mesas, delegas. Impones una estructura que reduce los canales: en vez de 1225 conversaciones, hay un organizador que habla con cinco responsables de mesa, y cada responsable coordina su mesa de diez. La estructura no es burocracia; es la única forma de que cincuenta personas hagan algo sin ahogarse en coordinación.

Un equipo de software es exactamente esa cena. Dos ingenieros coordinan con un mensaje. Cinco ya necesitan reuniones. Cincuenta en un solo equipo, "todos coordinando con todos", es el caos de la cena de cincuenta —nadie decide nada, todo el día es sincronización—. Y la solución es la misma: imponer estructura, dividir en equipos, delegar. Partir cincuenta personas en cinco equipos de diez es como partir la cena en cinco mesas: dentro de cada mesa la coordinación es manejable, y entre mesas solo coordinan unos pocos representantes. Esta lección es medir, con la fórmula, exactamente cuánto se ahorra al hacerlo —y por qué no hacerlo es matemáticamente insostenible—.

Ejemplo trabajado: cómo explota la coordinación

Vamos a ejecutar la fórmula n(n-1)/2 para ver la explosión con nuestros propios ojos, y luego a comparar dos organizaciones con la misma gente: 25 personas en un solo equipo grande, contra 25 personas en cinco equipos de cinco. La pregunta que responde el número es la del módulo: ¿por qué partir en equipos chicos, si es la misma gente?

# El costo de coordinacion: los canales de comunicacion crecen
# como n(n-1)/2 -- cuadraticamente, no linealmente.

def communication_paths(n):
    """Cuantos canales uno-a-uno hay entre n personas."""
    return n * (n - 1) // 2

print("Como explota el costo de coordinacion con el tamano del equipo:")
print(f"{'personas (n)':>13}{'canales n(n-1)/2':>20}")
for n in [2, 3, 5, 8, 10, 15, 20, 30, 50]:
    print(f"{n:>13}{communication_paths(n):>20}")

print()
# El mismo headcount, dos organizaciones distintas.
head = 25
one_big = communication_paths(head)                 # 1 equipo de 25
five_small = 5 * communication_paths(5)             # 5 equipos de 5 (canales internos)
inter_team = communication_paths(5)                 # canales entre los 5 equipos (peor caso)
print(f"25 personas en UN solo equipo   : {one_big} canales")
print(f"25 personas en 5 equipos de 5   : {five_small} canales internos"
      f" + {inter_team} inter-equipo = {five_small + inter_team}")
print()
factor = one_big / (five_small + inter_team)
print(f"Partir en equipos chicos baja los canales de {one_big} a {five_small + inter_team}")
print(f"-- un factor de {factor:.1f}x menos coordinacion, con la MISMA gente.")

Qué esperar. Al correrlo:

Como explota el costo de coordinacion con el tamano del equipo:
 personas (n)    canales n(n-1)/2
            2                   1
            3                   3
            5                  10
            8                  28
           10                  45
           15                 105
           20                 190
           30                 435
           50                1225

25 personas en UN solo equipo   : 300 canales
25 personas en 5 equipos de 5   : 50 canales internos + 10 inter-equipo = 60

Partir en equipos chicos baja los canales de 300 a 60
-- un factor de 5.0x menos coordinacion, con la MISMA gente.

Detente en la primera tabla, porque su forma es toda la lección. Fíjate cómo crecen los números: de 2 a 3 personas (una más) los canales suben de 1 a 3; de 10 a 20 personas (el doble) suben de 45 a 190 —más de cuatro veces, no el doble—; de 25 a 50 (el doble) suben de 300 a 1225 —otra vez cuatro veces—. Ese es el sello del crecimiento cuadrático: cada vez que duplicas el equipo, cuadruplicas la coordinación. Añadir la persona número 50 a un equipo no añade "un poco" de coordinación; añade 49 canales nuevos de golpe (los que esa persona tiene con cada uno de los otros 49). Por eso un equipo grande no se vuelve lento de forma gradual: se vuelve lento de forma acelerada, y llega un punto donde la gente pasa más tiempo en reuniones de sincronización que escribiendo código. La tabla te muestra el precipicio: 50 personas "coordinando entre todas" son 1225 conversaciones posibles, un número sencillamente ingobernable.

Ahora la comparación que responde la pregunta del módulo, y es contundente. Toma 25 personas. En un solo equipo grande, son 25×24/2 = 300 canales de comunicación posibles —un equipo de 25 ya está muy dentro de la zona de ahogo—. Toma exactamente las mismas 25 personas y pártelas en cinco equipos de cinco. Dentro de cada equipo hay 5×4/2 = 10 canales, y por cinco equipos son 50. Entre los cinco equipos, en el peor caso todos coordinan con todos, son 5×4/2 = 10 canales inter-equipo más. Total: 60 canales, contra los 300 del equipo único. La misma gente, el mismo trabajo, y la coordinación bajó por un factor de 5.

Aquí está la lección del módulo hecha número: la estructura no es burocracia, es reducción de coordinación. Partir en equipos no añade overhead —lo quita—. Los 300 canales del equipo gigante eran el verdadero overhead; los 60 canales de los cinco equipos son lo que queda cuando impones una estructura que evita que todos coordinen con todos. Y fíjate de dónde sale el ahorro: de que la mayoría de la coordinación se vuelve interna a cada equipo chico (barata, gente que se sienta junta) y solo un poquito queda entre equipos (10 canales, las fronteras). Este es el trueque exacto que la lección 3 anticipó: a cierta escala, pagar el costo de las fronteras (10 canales inter-equipo) sale muchísimo más barato que pagar el costo de la coordinación interna de un equipo gigante (300 canales). La fórmula acaba de fijar dónde vale la pena partir.

Un matiz honesto, porque el modelo simplifica. n(n-1)/2 cuenta los canales posibles, no los que se usan de verdad: en un equipo de 25, no todos hablan con todos todo el tiempo. El número es un techo, no una medición exacta del tiempo perdido. Pero el techo importa por dos razones: primero, porque marca el potencial de caos —cuantos más canales posibles, más difícil es que la información no se pierda o se contradiga—; segundo, porque la forma cuadrática se mantiene sin importar qué fracción de canales se use de verdad —si en un equipo de 10 se usa el 40% de los canales y en uno de 20 también el 40%, el de 20 sigue teniendo cuatro veces más coordinación real—. El modelo no dice "perderás exactamente 300 horas"; dice "la coordinación crece cuadráticamente, así que los equipos grandes se ahogan y partirlos ayuda muchísimo", y eso es robusto.

Profundización: el impuesto de Conway y el tamaño de dos pizzas

La fórmula n(n-1)/2 no solo explica por qué los equipos chicos ganan; explica también el concepto central de las team topologies —que veremos completo en la lección 7—: la carga cognitiva de un equipo y por qué debe mantenerse acotada.

Primero, el impuesto de Conway. Cada dependencia cross-team de tu sistema (las ocho que mediste en Mercado) es un canal de comunicación inter-equipo que tiene que existir para que el sistema funcione. Y los canales inter-equipo son los más caros de todos: no es gente que se sienta junta, son dos equipos con contextos distintos, prioridades distintas, a veces jefes distintos, que tienen que sincronizarse. Si dentro de un equipo un canal cuesta "un mensaje", entre equipos cuesta "una reunión, un ticket, una negociación de prioridades". Por eso la coordinación cross-team es el impuesto que Conway cobra por cada frontera que tu arquitectura cruza —y por eso el arquitecto que entiende esta fórmula diseña para minimizar las dependencias cross-team: no por elegancia, sino porque cada una es un canal caro que frena a dos equipos—. Reducir de 8 a 4 las dependencias cross-team de Mercado no es cosmética; es cortar a la mitad el impuesto de coordinación que el sistema le cobra a la organización todos los días.

Segundo, el tamaño de dos pizzas. Amazon popularizó la regla de que un equipo no debe ser más grande de lo que alimentan dos pizzas —unas 5 a 8 personas—. Ahora tienes la razón matemática: mira la tabla. Un equipo de 8 tiene 28 canales (manejable); uno de 15 tiene 105 (ya duele); uno de 20 tiene 190 (ahogo). El salto de 8 a 15 personas casi cuadruplica la coordinación. La regla de las dos pizzas no es folclor corporativo; es mantener a n en la zona donde n(n-1)/2 todavía es un número gobernable. Skelton & Pais lo formalizan como carga cognitiva: un equipo solo puede sostener en la cabeza cierta cantidad de sistema y cierta cantidad de coordinación, y pasarse de ahí lo vuelve lento y propenso a errores —no por falta de talento, sino por exceso de canales—. La consecuencia de diseño es doble: los equipos deben ser chicos (para acotar la coordinación interna) y los pedazos de sistema que poseen deben ser acotados (para acotar la carga que cargan). Un equipo chico dueño de un sistema enorme se ahoga igual, por el lado de la carga cognitiva del código.

La síntesis, que amarra el módulo: la organización ideal según Conway no es "un equipo grande que evita fronteras" (se ahoga en coordinación interna, 300 canales) ni "muchísimos equipos minúsculos que fragmentan todo" (se ahogan en coordinación entre equipos, demasiadas fronteras caras). Es un punto intermedio: equipos lo bastante chicos para que la coordinación interna sea barata, lo bastante pocos para que las fronteras entre ellos sean manejables, y con las fronteras puestas donde el sistema tiene sus junturas naturales —para que las dependencias cross-team, el impuesto caro, sean las mínimas—. Encontrar ese punto es el arte que las lecciones 6 y 7 convierten en método.

Errores comunes

Creer que la coordinación crece linealmente (de intuición engañosa). Qué pasa: un manager piensa "el equipo va lento, le agrego tres personas y avanza más", y el equipo se vuelve más lento —el clásico de The Mythical Man-Month: agregar gente a un proyecto atrasado lo atrasa más—. Por qué pasa: la intuición dice que el trabajo se reparte (lineal), pero la coordinación se multiplica (cuadrática); las tres personas nuevas añaden tres pares de manos y decenas de canales de comunicación. Cómo detectarlo: si cada vez que creces el equipo la velocidad por persona baja, estás pagando el impuesto cuadrático. Cómo corregirlo: en vez de engordar un equipo, pártelo —agrega un equipo nuevo, no una persona más al gigante—; la tabla muestra por qué cinco equipos de cinco baten a uno de veinticinco.

Partir en demasiados equipos minúsculos (de sobre-fragmentación). Qué pasa: para "reducir el tamaño de los equipos", alguien crea quince equipos de dos personas, y ahora la coordinación interna de cada equipo es trivial pero la coordinación entre los quince equipos es un infierno —demasiadas fronteras, demasiados canales inter-equipo caros—. Por qué pasa: se optimiza solo el costo interno e se ignora que las fronteras también cuestan. Cómo detectarlo: si tus equipos son tan chicos que cada feature necesita coordinar entre cinco de ellos, sobre-fragmentaste. Cómo corregirlo: recuerda que el objetivo es minimizar la coordinación total (interna + entre equipos), no solo la interna; el punto óptimo es equipos chicos pero no minúsculos, con fronteras alineadas al sistema para que los cruces sean pocos.

Ignorar que las fronteras mal puestas multiplican el costo inter-equipo (de fronteras equivocadas). Qué pasa: se parte en cinco equipos, pero las fronteras cortan el sistema por donde no debían, así que casi todo feature cruza varios equipos —como en Mercado, con el checkout cruzando cuatro—. El resultado: pocos canales dentro de cada equipo pero muchísimos inter-equipo, el impuesto de Conway al máximo. Por qué pasa: se elige el tamaño de los equipos (chicos, bien) pero no dónde van las fronteras (mal). Cómo detectarlo: alta proporción de dependencias cross-team (Mercado: 61.5%) significa fronteras mal puestas. Cómo corregirlo: no basta con equipos chicos; las fronteras deben coincidir con las junturas naturales del sistema, para que la coordinación cara (inter-equipo) sea la mínima —justo lo que la maniobra inversa (lección 6) diseña a propósito—.

Ejercicios

Ejercicio 1 — Calcula el punto de quiebre. Usa la fórmula n(n-1)/2. (a) ¿Cuántos canales tiene un equipo de 12? (b) Si ese equipo de 12 se parte en dos equipos de 6, ¿cuántos canales internos hay en total, y cuántos inter-equipo (peor caso, los dos equipos coordinando)? (c) ¿Cuánto se ahorró?

Ver solución
  • (a) Equipo de 12: 12×11/2 = 66 canales.
  • (b) Dos equipos de 6: cada uno tiene 6×5/2 = 15 canales internos, así que 2×15 = 30 internos en total. Entre los dos equipos, en el peor caso, 2×1/2 = 1 canal inter-equipo (dos equipos → un solo par). Total: 30 + 1 = 31 canales.
  • (c) Ahorro: de 66 a 31 canales, poco más de la mitad. Factor ≈ 66/31 ≈ 2.1x.

La lección: incluso partir un equipo mediano (12) en dos baja la coordinación a menos de la mitad. Y fíjate que la coordinación inter-equipo (1 canal) es minúscula comparada con el ahorro interno —por eso partir casi siempre gana, siempre que las fronteras estén bien puestas—. Cuanto más grande el equipo original, más dramático el ahorro (partir 50 en 5 ahorró factor 5x; partir 12 en 2 ahorra 2.1x), porque el término cuadrático castiga más a los equipos más grandes.

Ejercicio 2 — El manager que suma en vez de partir. Un equipo de 10 personas va atrasado. El manager propone contratar 5 más para llegar a 15 "y así avanzar 50% más rápido". Usando la fórmula, explica por qué probablemente vaya a avanzar menos, no más, y qué debió proponer.

Ver solución

Por qué avanza menos: los canales de comunicación pasan de 10×9/2 = 45 (equipo de 10) a 15×14/2 = 105 (equipo de 15). La coordinación no creció 50% (como el headcount), creció 133% —de 45 a 105—. Además, las 5 personas nuevas necesitan onboarding, que consume tiempo de las 10 existentes. En el corto plazo, el equipo dedica tanto tiempo extra a coordinar y a incorporar gente que la capacidad neta de construir baja. Es el Mythical Man-Month: agregar gente a un proyecto atrasado lo atrasa más, porque la coordinación crece más rápido que la capacidad.

Qué debió proponer: en vez de engordar el equipo de 10 a 15, crear un segundo equipo. Partir el trabajo en dos áreas con una frontera limpia, formar un equipo de ~5-8 para la nueva, y dejar el original acotado. Así la coordinación interna de cada equipo se mantiene manejable (8×7/2 = 28 y 7×6/2 = 21 en vez de un solo 105), y solo se paga el costo de una frontera inter-equipo. La regla: cuando un equipo va lento por tamaño, no le agregues personas —divídelo—. Y la condición: la frontera entre los dos equipos tiene que coincidir con una juntura natural del sistema, o el ahorro se lo come el impuesto de coordinación cross-team (ejercicio 3).

Ejercicio 3 — Fronteras buenas contra fronteras malas. Dos empresas parten 20 personas en 4 equipos de 5. La empresa A pone las fronteras donde el sistema tiene junturas naturales, y le quedan 3 dependencias cross-team. La empresa B pone las fronteras a lo loco, y le quedan 15 dependencias cross-team. Las dos tienen la misma coordinación interna. ¿Cuál va más rápido y por qué? ¿Qué dice esto sobre "hacer equipos chicos" como consejo aislado?

Ver solución

Coordinación interna (igual en las dos): 4 equipos de 5 → 4 × (5×4/2) = 4×10 = 40 canales internos. Idéntica.

Coordinación inter-equipo (la diferencia): la empresa A tiene 3 dependencias cross-team, así que ~3 canales inter-equipo caros. La empresa B tiene 15, así que ~15 canales inter-equipo caros —cinco veces más—. Recordando que un canal inter-equipo es mucho más caro que uno interno (dos equipos con contextos distintos, no gente que se sienta junta), la empresa B paga un impuesto de coordinación enorme que A no paga.

Cuál va más rápido: la empresa A, por lejos. Tiene la misma coordinación interna pero una fracción del impuesto inter-equipo. La empresa B, a pesar de tener "equipos chicos" (5 personas, tamaño correcto), se ahoga porque casi todo lo que hace cruza fronteras y exige coordinar entre equipos.

Qué dice sobre "hacer equipos chicos": que es un consejo incompleto. El tamaño chico solo optimiza la coordinación interna. Pero el impuesto que de verdad duele a escala es la coordinación inter-equipo, y eso depende de dónde pones las fronteras, no del tamaño de los equipos. "Equipos chicos con fronteras equivocadas" (empresa B) puede ser peor que "equipos un poco más grandes con fronteras correctas". Por eso el módulo no se detiene en "haz equipos chicos": las lecciones 5, 6 y 7 son sobre dónde van las fronteras —alinearlas con las junturas del sistema para que las dependencias cross-team, el impuesto caro, sean las mínimas—. El tamaño es la mitad fácil; la ubicación de las fronteras es la mitad que hace o rompe.

Resumen y siguiente paso

En esta lección conociste el motor económico de la Ley de Conway: la coordinación crece cuadráticamente, según n(n-1)/2. Con la cena que pasa de un amigo a cincuenta viste que arriba de cierto tamaño "que todos coordinen con todos" es imposible, y que la solución es imponer estructura —dividir en mesas, delegar—. Y lo mediste ejecutando: la tabla que muestra la explosión (2→1, 10→45, 50→1225), y la comparación que responde la pregunta del módulo —25 personas en un equipo son 300 canales; las mismas 25 en cinco equipos de cinco son 60, un factor de 5x menos coordinación con la misma gente—. Entendiste que la estructura no es overhead sino reducción de coordinación, que la coordinación cross-team es el impuesto caro que Conway cobra por cada frontera, que la regla de las dos pizzas es n(n-1)/2 aplicada, y que "equipos chicos" es solo la mitad del consejo —la otra mitad es dónde van las fronteras—.

Antes de avanzar deberías poder: calcular los canales de comunicación de un equipo y explicar por qué crecen cuadráticamente; argumentar con números por qué partir un equipo grande baja la coordinación (y por qué sumarle gente la sube); distinguir el costo de coordinación interno del inter-equipo; y explicar por qué las fronteras mal puestas multiplican el impuesto caro aunque los equipos sean chicos.

Lo que sigue es aplicar todo esto a la enfermedad concreta de Mercado. En la lección 5 vas a medir la fricción del módulo que cruza dos equipos —el checkout, que orders y payments se disputan—. Vas a ver que cuando un solo módulo obliga a cuatro equipos a coordinar simultáneamente, ese módulo concentra una porción enorme del impuesto de Conway de todo el sistema. Con la fórmula de esta lección en la mano, vas a entender por qué esa fricción es tan cara —cada par de equipos que debe estar en la sala es un canal inter-equipo del más costoso— y vas a poder señalar, con un número, cuál módulo es el que más frena a Mercado.

Recursos

← Anterior3. El monolito es tu primer organigramaSiguiente →5. Los módulos que cruzan fronteras de equipo