8. Proyecto: lograr que 5 squads adopten un estándar

Descripción

Esta es tu graduación del módulo. Durante siete lecciones aprendiste por qué el arquitecto lidera con autoridad prestada y no del organigrama, por qué influir vence a mandar, cómo la confianza es una cuenta que se gana y se gasta, cómo dar guardrailes en vez de ser una puerta, cómo discrepar sin bloquear, dónde ocurren las conversaciones que sostienen la arquitectura, y cómo construir consenso en vez de ganar debates. Todo eso lo viste aplicado en pedazos. Ahora te toca a ti, de principio a fin, sobre una situación concreta: lograr que las cinco squads de Mercado adopten un estándar común sin que puedas ordenárselo. La razón de hacerlo tú, completo, es la de siempre y es dura: si te dejara repetir los ejemplos de las lecciones, no sabría si aprendiste el oficio o memorizaste las respuestas. Con un rollout real que planeas de cero, la única forma de resolverlo es aplicar el método —y esa es, exactamente, la prueba de que el módulo funcionó—.

Tu entregable son tres artefactos: (1) el mapa de confianza y disposición de cada squad —quién es early adopter, quién es escéptico, cuál es tu saldo con cada una—; (2) el plan de adopción que combina las herramientas del módulo —por dónde siembras, qué guardrail construyes, qué load-bearing conversations tienes, cómo manejas la squad que discrepa—; y (3) la medición ejecutada, en Python, del reflejo del liderazgo (mandar) contra tu plan (influencia + guardrail), sobre dos números que resumen el módulo: la adopción genuina y la carga del arquitecto. Ninguna parte requiere construir el estándar: es puro trabajo de liderazgo —mapear, planear, medir—, que es justo lo que separa a un arquitecto que diseña de uno que logra que se adopte. Constrúyelo tú primero; leer la solución de referencia sin haberlo intentado es como leer el marcador de un partido que no jugaste.

Conexión con el módulo: este proyecto cierra el arco. Las lecciones 2 y 3 te dieron el porqué y la moneda (influir, la confianza); las lecciones 4 a 7 te dieron las prácticas (guardrailes, disagree-and-commit, load-bearing conversations, consenso). Aquí las usas todas a la vez sobre un rollout real. Y con esta lección se cierra el módulo: al final está el resumen de las ocho lecciones y el puente hacia el módulo 5, donde vas a aprender a traducir metas de negocio en atributos de calidad —el arquitecto hablando con el stakeholder, después de aprender a hablar con los equipos—.

El caso del proyecto: el estándar de observabilidad

La situación —tuya para resolver— es esta:

El VP de ingeniería quiere que, para el fin del trimestre (doce semanas), las cinco squads de Mercado —catalog, orders, payments, shipping, platform— adopten un estándar de observabilidad común: logs estructurados en JSON, un trace-id que viaje a través de los servicios, y un contrato de error unificado. La razón de negocio es real: hoy, cuando algo falla en producción, rastrear el problema a través de los cinco servicios toma horas porque cada squad emite logs a su manera. El liderazgo, con prisa, propone la vía obvia: mandar un comunicado de que el estándar es obligatorio y meterlo en el sprint de todas las squads. Tú, como arquitecto, no eres el jefe de ninguna squad (tu autoridad formal es 0%), y tu trabajo es lograr la adopción real —no el "hecho" nominal— con el método del módulo.

El contexto de cada squad (te lo da tu conocimiento del terreno, para que no tengas que inventarlo):

• platform — Sufre más que nadie el problema: son quienes reciben los tickets cuando algo falla y no se puede rastrear. Tu saldo de confianza con ellos es alto (los ayudaste en varios incidentes). Candidata natural a early adopter.
• catalog — Equipo pragmático, abierto a mejoras si les bajas el costo. Saldo neutro-positivo. Adoptaría si ve evidencia.
• orders — Ocupados, con un backlog apretado; no están en contra, pero "no tienen tiempo". Saldo neutro. Se mueven si el costo de adoptar es bajo.
• shipping — Escépticos por experiencia: en el pasado les impusieron un estándar que resultó un dolor. Saldo bajo. Van a resistir cualquier cosa que huela a imposición.
• payments — Tienen una preocupación técnica legítima: su formato de logs actual está ligado a un requisito de auditoría (PCI), y temen que el estándar rompa ese cumplimiento. Saldo neutro, pero con una objeción real que hay que resolver.

Fíjate en la mezcla: una early adopter clara (platform), dos pragmáticas (catalog, orders), una escéptica por experiencia (shipping), y una con una objeción técnica legítima (payments). El método del módulo debería tener algo distinto que decir sobre cada una. No re-enseñes cómo funciona el logging estructurado ni el tracing —eso es de otra guía—; tu trabajo es liderar la adopción.

Lo que tienes que entregar

Sigue los pasos en orden; cada uno se apoya en el anterior.

Parte 1 — El mapa de confianza y disposición

Para cada una de las cinco squads, escribe: tu saldo de confianza aproximado (alto/neutro/bajo), su disposición (early adopter / pragmática / escéptica / con objeción), y qué palanca del módulo usarías con ella. Identifica a ojo por dónde empezarías y cuál será la más difícil —antes de planear el rollout—.

Parte 2 — El plan de adopción

Diseña el rollout de doce semanas combinando las herramientas del módulo: por dónde siembras (early adopter, lección 2), qué guardrail construyes para que adoptar sea barato y no tengas que aprobar cada PR (lección 4), qué load-bearing conversations tienes y con quién (lección 6), cómo manejas la objeción legítima de payments (disagree-and-commit / escalar, lección 5), y cómo llegas a un consenso que las cinco hagan suyo (lección 7). No "convéncelos": un plan concreto, semana a semana o por fases.

Parte 3 — La medición ejecutada

Escribe y corre el Python que compara dos escenarios sobre las doce semanas: el mandato (el reflejo del liderazgo) contra tu plan de influencia + guardrail, midiendo dos cosas: la adopción genuina (de las 5 squads) y la carga del arquitecto (cuántos PRs de migración tiene que revisar). Entrega los números reales, corridos, no citados de memoria. Reusa los motores de las lecciones 2 y 4.

La rúbrica

Así se evalúa el proyecto. No es por extensión ni por elegancia: es por si el liderazgo está bien pensado y bien defendido con evidencia.

Criterio	No cumple	Cumple	Sobresale
Mapa de confianza y disposición	Trata a las 5 squads igual	Distingue disposición y saldo por squad	Además nombra la palanca del módulo para cada una
Plan de adopción	"Mando un correo" o "los convenzo"	Rollout que usa early adopter + guardrail + conversaciones	Además maneja bien la objeción de payments (escalar vs commit) y busca consenso
Medición ejecutada	Números citados de memoria o inventados	Adopción y carga corridas en Python	Además interpreta los dos números y declara supuestos
Criterio	Manda porque es más rápido	Justifica la influencia con la adopción medida	Además dice cuándo el mandato sí sería aceptable

El criterio que más pesa, y el que separa a un líder técnico de alguien que solo manda comunicados, es la combinación del plan con la medición ejecutada: si entregas un plan bonito pero los números salieron de tu cabeza y no de correr el código, no mediste —afirmaste con cifras inventadas, que es peor, porque finge rigor—.

La solución de referencia

Intenta el proyecto entero antes de seguir. Lo que viene es una solución correcta, no la única.

Parte 1 — El mapa de confianza y disposición

Squad	Saldo	Disposición	Palanca del módulo
platform	Alto	Early adopter	Sembrar aquí (lección 2): tienen el dolor que el estándar cura y confían en mí. Primer sí, y fuente de evidencia.
catalog	Neutro-positivo	Pragmática	Bajar el costo de adoptar (guardrail, lección 4): adopta si le doy librería + evidencia de platform.
orders	Neutro	Pragmática, sin tiempo	Guardrail + camino pavimentado (lección 4): solo se mueve si adoptar cuesta casi nada; hacer que lo fácil sea lo correcto.
shipping	Bajo	Escéptica por experiencia	Confianza + load-bearing conversation (lecciones 3, 6): 1:1 para escuchar su mala experiencia previa; no imponer nada, o resisten en automático.
payments	Neutro, con objeción	Objeción técnica legítima (PCI)	Disagree-and-commit / integrar la objeción (lecciones 5, 7): resolver su preocupación de auditoría antes de pedir adopción.

Lo que veo a ojo, antes de planear: empiezo por platform (early adopter con saldo alto) porque es el sí más barato y la mejor fuente de evidencia. La más difícil no es la escéptica (shipping) sino payments: su objeción es técnica y legítima (el estándar podría romper su cumplimiento PCI), así que no se resuelve con influencia ni con evidencia —se resuelve resolviendo la objeción de verdad, o el estándar mismo está mal para ellos—. Si ignoro esa objeción y empujo, o rompo su cumplimiento (desastre) o los pierdo. shipping es difícil pero manejable: su resistencia es a la imposición, no al estándar, así que la clave es no imponer.

Parte 2 — El plan de adopción

Semanas 1-3 — Sembrar en el early adopter y construir el guardrail.

• Trabajar con platform (early adopter): ayudarlos a migrar un servicio al estándar. Como ya sufren el problema y confían en mí, el sí es barato. Objetivo: que ocurra el momento de valor —el primer incidente que rastrean en minutos en vez de horas—.
• En paralelo, construir el guardrail que hará barata la adopción para las demás: una librería compartida de observabilidad (que emite logs en JSON con trace-id automáticamente, con la forma correcta por defecto) y un check de CI (fitness function) que verifica el formato sin que yo revise cada PR. Esto es el camino pavimentado: hacer que lo fácil sea lo correcto (lección 4). Así no me vuelvo la puerta que aprueba cada migración.

Semanas 2-4 — La load-bearing conversation con payments (la objeción legítima).

• Un 1:1 con el líder de payments antes de pedirles nada: "¿qué te frenaría de adoptar esto?". Escuchar la preocupación de PCI a fondo (lección 6). Es una objeción real, no resistencia.
• Resolverla en el diseño: asegurar que la librería compartida preserve (o incluso mejore) los campos que el cumplimiento PCI exige, y que no exponga datos sensibles en los logs. Si el estándar no puede acomodar PCI, cambiar el estándar —eso es escuchar de verdad—. Aquí es disagree-and-commit bien hecho: su objeción mejora la decisión (lección 5). Y si payments hubiera querido, por ejemplo, guardar datos sin cifrar "para simplificar", ahí sí escalaría (riesgo grave); pero su objeción es lo contrario —proteger el cumplimiento—, así que la integro.

Semanas 3-6 — Difundir con evidencia a las pragmáticas.

• Con la evidencia de platform (el incidente rastreado en minutos, contado por ellos), acercarme a catalog y orders. Para ellas el argumento no es mi autoridad (no tengo) sino: "a platform le funcionó, aquí está la librería lista, migrar te cuesta 20 minutos". El guardrail (librería + camino pavimentado) hace que el sí sea barato para las pragmáticas sin tiempo.

Semanas 4-8 — La conversación con shipping (la escéptica).

• 1:1 con shipping para escuchar su mala experiencia previa (el estándar que les impusieron y les dolió). Reconocer esa experiencia (depósito de confianza, lección 3), y ser explícito en que esto no es una imposición: no hay orden, hay una librería que les ahorra trabajo y evidencia de que a otras squads les sirvió. Dejar que decidan. Con la escéptica, la clave es que la adopción se sienta suya, no impuesta —o resisten en automático—.

Semanas 8-11 — Construir el consenso y la junta de ratificación.

• Para cuando convoque la junta con las cinco squads, ya tengo el sí (o el camino al sí) de cada una en privado: platform ya lo usa, payments tiene su objeción resuelta, catalog y orders vieron la evidencia y el camino barato, shipping decidió sin presión. La junta ratifica un consenso ya construido (lección 6), no decide en frío. El consenso no es que todas amen el estándar; es que todas puedan decir "lo entiendo, mis preocupaciones se escucharon, me comprometo" (lección 7).

Semana 12 — Cierre.

• Adopción genuina de las cinco squads, sostenida por la librería (guardrail) que mantiene el estándar sin que yo revise cada PR. Lideré el estándar sin ordenarlo ni volverme el cuello de botella.

Parte 3 — La medición ejecutada

# Proyecto: lograr que las 5 squads adopten UN estandar de observabilidad
# (logging estructurado + trace-id + contrato de error comun) en 12 semanas,
# SIN autoridad para ordenarlo. Comparamos el reflejo del liderazgo (MANDATE)
# contra el plan del arquitecto (INFLUENCE + GUARDRAIL), midiendo dos cosas:
# adopcion GENUINA y carga de revision del arquitecto.

SQUADS = 5
WEEKS = 12

# --- Adopcion genuina (motor de la leccion 2) ---
def influence(seed, contagion):
    a, hist = seed, [seed]
    for _ in range(WEEKS):
        a = min(SQUADS, a + contagion * a * ((SQUADS - a) / SQUADS))
        hist.append(a)
    return hist

def mandate(g0, backslide):
    g, hist = g0, [g0]
    for _ in range(WEEKS):
        g = max(0.0, g - backslide * g)
        hist.append(g)
    return hist

adopt_influence = influence(seed=1.0, contagion=0.75)
adopt_mandate = mandate(g0=2.0, backslide=0.12)

# --- Carga del arquitecto (motor de la leccion 4) ---
# Al migrar al estandar, cada squad abre PRs. Con MANDATE el arquitecto revisa
# cada PR (puerta). Con GUARDRAIL una libreria compartida + un check de CI
# (fitness function) aprueban la rutina; el arquitecto solo revisa las
# excepciones reales.
PRS_PER_SQUAD = 8
total_prs = SQUADS * PRS_PER_SQUAD
EXCEPTIONS = 5                       # PRs que de verdad piden criterio de arquitecto
gate_reviews = total_prs             # revisa todo
guardrail_reviews = EXCEPTIONS       # revisa solo lo que importa

print("ADOPCION GENUINA del estandar (de 5 squads):")
print(f"{'week':<8}{'mandate':>10}{'influence+guardrail':>21}")
for w in (0, 4, 8, 12):
    print(f"{w:<8}{adopt_mandate[w]:>10.2f}{adopt_influence[w]:>21.2f}")
print()
print(f"Semana 12: mandato = {adopt_mandate[-1]:.1f}/5   influencia = {adopt_influence[-1]:.1f}/5")
print()
print("CARGA DEL ARQUITECTO durante la migracion:")
print(f"{'design':<12}{'total_prs':>11}{'arch_reviews':>14}")
print(f"{'GATE':<12}{total_prs:>11}{gate_reviews:>14}")
print(f"{'GUARDRAIL':<12}{total_prs:>11}{guardrail_reviews:>14}")
print()
print(f"El mandato consigue papeleo (5/5 nominal) pero {adopt_mandate[-1]:.1f}/5 real, y pone")
print(f"al arquitecto a revisar {gate_reviews} PRs: cuello de botella.")
print(f"La influencia con guardrailes llega a {adopt_influence[-1]:.1f}/5 genuina y deja al")
print(f"arquitecto revisando solo {guardrail_reviews}: lidero el estandar sin ordenarlo ni ser la puerta.")

Qué esperar. Al correrlo:

ADOPCION GENUINA del estandar (de 5 squads):
week       mandate  influence+guardrail
0             2.00                 1.00
4             1.20                 4.18
8             0.72                 4.99
12            0.43                 5.00

Semana 12: mandato = 0.4/5   influencia = 5.0/5

CARGA DEL ARQUITECTO durante la migracion:
design        total_prs  arch_reviews
GATE                 40            40
GUARDRAIL            40             5

El mandato consigue papeleo (5/5 nominal) pero 0.4/5 real, y pone
al arquitecto a revisar 40 PRs: cuello de botella.
La influencia con guardrailes llega a 5.0/5 genuina y deja al
arquitecto revisando solo 5: lidero el estandar sin ordenarlo ni ser la puerta.

Lee los dos bloques juntos, porque muestran las dos caras del módulo en un mismo caso.

El primer bloque es la adopción genuina (motor de la lección 2). El mandato arranca arriba —2.0 el día cero, y 5/5 si contamos el "hecho" nominal que las squads reportan bajo presión— pero se erosiona a 0.4 de 5 real para la semana 12: el estándar impuesto se cumple de dientes para afuera (logs en JSON pero vacíos, trace-id que no se propaga) y se abandona. La influencia + guardrail arranca en 1.0 (solo platform), se difunde con la evidencia y el camino pavimentado, y llega a 5.0 de 5 genuina, donde se queda —las cinco squads lo usan de verdad porque lo adoptaron por convicción y la librería lo mantiene fácil—.

El segundo bloque es la carga del arquitecto (motor de la lección 4). Bajo el mandato, como no hay guardrail, el arquitecto termina revisando cada PR de migración para verificar que el estándar se aplicó —40 PRs, el cuello de botella—. Con el guardrail (librería que hace fácil lo correcto + check de CI que verifica el formato), la automatización aprueba la rutina y el arquitecto revisa solo las 5 excepciones reales (los casos raros, como la integración de PCI de payments). Ocho veces menos carga, y la que queda es exactamente la que necesita su criterio.

El punto del proyecto es que estos dos números están conectados, y esa conexión es la tesis del módulo. El mandato falla por los dos lados a la vez: consigue adopción hueca (0.4) y vuelve al arquitecto la puerta (40 revisiones). No es coincidencia: mandar sin construir el camino obliga a vigilar el cumplimiento uno por uno, y vigilar el cumplimiento no produce convicción. La influencia con guardrailes gana por los dos lados a la vez: adopción genuina (5.0) porque se construyó con evidencia y consenso, y carga baja (5) porque el guardrail sostiene el estándar sin el arquitecto. Liderar sin autoridad no es elegir entre adopción y no-ser-cuello-de-botella; es conseguir las dos con el mismo método —o perder las dos con el mandato—.

Los supuestos que declaro: los parámetros de difusión (seed 1.0, contagio 0.75) y de erosión (0.12) son ilustrativos, elegidos para mostrar la forma robusta (la influencia se difunde y se queda; el mandato se erosiona), no medidos de Mercado. La clasificación de 40 PRs con 5 excepciones asume que la mayoría de la migración es rutinaria (la cubre la librería) y solo unos casos tocan criterio real —lo cual es cierto porque construí la librería; sin ella, muchos más PRs necesitarían revisión—. El modelo captura la estructura del problema, no una predicción exacta de semanas.

Ejercicios

Estos ejercicios transfieren el método a otras situaciones de liderazgo de Mercado, para que confirmes que aprendiste a liderar y no a repetir un rollout.

Ejercicio 1 — La squad que reporta "hecho" en la semana 2. Bajo tu plan de influencia, en la semana 2 la squad de orders te dice "ya adoptamos el estándar, está hecho". Suena bien, pero recuerdas la lección 2. ¿Qué señal te haría sospechar que es cumplimiento nominal y no adopción genuina, y cómo lo verificarías sin ofender a la squad?

Ver solución

La señal sospechosa: orders era la squad "pragmática pero sin tiempo", con saldo neutro, que en tu mapa solo se movería si el costo de adoptar era casi cero —y estás apenas en la semana 2, cuando el guardrail (la librería) quizás ni estaba listo para ellos y la evidencia de platform apenas empezaba—. Un "hecho" tan rápido de una squad que no tenía tiempo ni una razón fuerte para priorizarlo es sospechoso: probablemente marcaron el checkbox (importaron la librería, o peor, copiaron un formato) sin adoptarlo de verdad. La velocidad y la falta de preguntas son la bandera (lección 2): la adopción real genera dudas, fricción, pedidos de ayuda; un "hecho" liso y veloz suele ser nominal.

Cómo verificarlo sin ofender: no acusar ("¿de verdad lo hicieron?"), sino verificar usando el estándar, con curiosidad genuina y ofreciendo valor. Por ejemplo: "¡qué bueno! Oye, aprovechemos —hagamos juntos un rastreo de prueba de un error a través de orders, así ven el trace-id en acción y me dicen si les falta algo". Si el estándar está de verdad adoptado, el rastreo funciona y todos ganan. Si es nominal, el rastreo falla (logs vacíos, trace-id que no se propaga) y lo descubren ellos mismos en el intento, sin que tú los acuses —y ahí ofreces ayudarlos a cerrarlo bien, convirtiendo la verificación en un depósito de confianza en vez de una auditoría—. La clave: verificar por el uso real, no por el reporte, y hacerlo de forma que ayude en vez de fiscalizar.

Ejercicio 2 — El VP presiona por el mandato. A mitad del trimestre, el VP se impacienta: "esto va lento, mejor mando un comunicado de que es obligatorio y lo metemos en todos los sprints". Con los números del proyecto, argumenta por qué el mandato conseguiría menos que tu plan, y reconoce en qué tendría razón el VP (cuándo el mandato sí ayuda).

Ver solución

Por qué el mandato conseguiría menos: con los números del proyecto, el mandato lleva la adopción genuina a 0.4 de 5 para la semana 12 (cumplimiento nominal que se erosiona), mientras el plan de influencia llega a 5.0 de 5 real. Y de paso, el mandato pone al arquitecto (o a alguien) a revisar los 40 PRs de migración para verificar cumplimiento —el cuello de botella— contra los 5 del guardrail. El comunicado del VP conseguiría exactamente lo que el arquitecto quiere evitar: un tablero que dice "5/5 adoptado" (el papeleo) sobre un sistema donde, cuando falle en producción, los logs seguirán sin servir para rastrear —porque se llenaron de basura para cumplir el checkbox—. La prisa del mandato compra un titular y pierde el resultado.

En qué tendría razón el VP (cuándo el mandato sí ayuda): el VP tiene razón en la urgencia —doce semanas es un plazo real y "esto va lento" puede ser una preocupación válida—. Y el mandato sí tiene un lugar legítimo: como respaldo del consenso, no como sustituto. Una vez que el plan de influencia construyó la adopción genuina (las squads ya lo usan porque quisieron), un comunicado del VP declarando el estándar "oficial" ayuda —le da respaldo institucional a algo que ya tiene convicción, cierra a los últimos rezagados, y evita que una squad nueva lo ignore—. El orden importa: mandato después del consenso amplifica; mandato en vez de consenso erosiona. También el mandato sirve para lo verdaderamente no negociable (seguridad, cumplimiento legal), donde no hay espacio para difundir por convicción. La respuesta al VP no es "el mandato nunca"; es "primero construyamos la adopción real —que ya va en camino, aquí está la evidencia de platform— y luego, si quieres, tu comunicado la sella; al revés, conseguimos papeleo que se cae".

Ejercicio 3 — La objeción legítima contra la resistencia caprichosa. En tu plan, tratas la objeción de payments (PCI) muy distinto de la resistencia de shipping (mala experiencia previa): a una la integras, a la otra la trabajas con confianza. Explica por qué la misma actitud ("escuchar y adaptarse") se aplica distinto a cada una, y qué harías si una squad, en cambio, se resistiera sin ninguna razón real —solo "no quiero"—.

Ver solución

Por qué la misma actitud se aplica distinto:

• payments (objeción técnica legítima): su preocupación —que el estándar rompa el cumplimiento PCI— es un hecho técnico que, si es cierto, significa que el estándar está mal para ellos. Escuchar aquí no es solo construir confianza; es recoger información que mejora la decisión (disagree-and-commit, lección 5: su objeción hace mejor el estándar). La adaptación es técnica: cambiar la librería o el estándar para acomodar PCI. Si ignoro esto, no pierdo adopción —rompo su cumplimiento legal, un desastre—.

• shipping (resistencia por experiencia): su reticencia no es una objeción técnica al estándar; es una herida de confianza de un mal precedente (les impusieron algo que dolió). Escuchar aquí es sobre todo reparar la relación (lección 3): reconocer su mala experiencia, y demostrar con actos —no imponer, dejarlos decidir, darles la librería que les ahorra trabajo— que esta vez es distinto. La adaptación es relacional y de proceso, no técnica: el estándar puede estar perfecto; lo que hay que cambiar es cómo se los presento (como oferta, no como orden).

La misma actitud (escuchar y adaptarse) con dos contenidos: a payments le adapto el estándar (información técnica); a shipping le adapto el acercamiento (confianza y proceso). Confundirlos sería el error: si trato la objeción PCI de payments como "resistencia a superar con confianza", rompo su cumplimiento; si trato la reticencia de shipping como "objeción técnica a resolver", no entiendo que su problema es que no confían, no que el estándar esté mal.

Si una squad se resiste sin razón real ("no quiero"): primero, sospechar que sí hay una razón que no están diciendo —el "no quiero" liso suele esconder un miedo (a que les quite tiempo, a que los evalúen mal, a un dolor pasado) que una load-bearing conversation en privado (lección 6) puede sacar a la luz: "¿qué es lo que de verdad te frenaría?". La mayoría de las "resistencias caprichosas" son objeciones no dichas. Si tras escuchar de verdad resulta que no hay ninguna razón —solo inercia—, entonces la palanca es la difusión y la prueba social (lección 2): no pelear con esa squad, sino dejar que las otras cuatro adopten y que la evidencia y la presión de pares hagan el trabajo ("las demás ya lo usan y les sirve"). El rezagado sin razón real cede ante la evidencia acumulada, no ante mi insistencia —y si al final una sola squad no adopta algo que a las otras cuatro les sirve, eso es información para el VP (respaldo institucional), no una batalla que yo deba ganar gastando toda mi confianza—.

Resumen del módulo y hacia dónde sigues

Con este proyecto cierras el módulo 4, el módulo del liderazgo. Empezaste con la tesis —tener razón no es tener poder: el arquitecto lidera con autoridad prestada, no del organigrama— y el director de orquesta que logra que cuarenta músicos suenen juntos sin tocar ningún instrumento, midiendo que su autoridad formal sobre las cinco squads es 0% (lección 1). Convertiste esa tesis en el porqué medido: influir vence a mandar, porque la orden consigue cumplimiento nominal que se erosiona (0.4/5) mientras la influencia difunde adopción genuina que se queda (5.0/5) (lección 2). Conociste la moneda: la cuenta de confianza que se deposita (acertar, ayudar, admitir errores, dar crédito) y se retira (imponer, fallar tras insistir, robar crédito), y por la que la misma propuesta correcta se sigue (+10) o se ignora (−10) (lección 3). Aprendiste a influir a escala sin ahogarte: guardrailes en vez de puertas —fusionar 50 de 50 en vez de 15, tocar solo los 6 que tocan fronteras— y a escalar como multiplicador que decide y mentorea (lección 4). Aprendiste a discrepar sin bloquear: disagree and commit —el punto medio (9 semanas) entre el bloqueador que frena todo (15) y el que cede y deja pasar la falla— (lección 5). Descubriste dónde ocurre de verdad el liderazgo: las load-bearing conversations —la decisión que se aplaza en la junta en frío (5/10) y se decide en los 1:1 previos (10/10)— (lección 6). Y aprendiste a hacer que las decisiones se queden: construir consenso —la decisión buena que todos hacen suya (8 × 0.95 = 7.6) le gana a la perfecta que nadie ejecuta (10 × 0.40 = 4.0)— (lección 7). Aquí, en el proyecto, lo hiciste todo tú: mapeaste la confianza y disposición de cinco squads, planeaste un rollout que combina las seis herramientas, y mediste que la influencia con guardrailes gana por los dos lados —adopción genuina y carga baja— donde el mandato pierde por los dos.

La capacidad que te llevas: ante cualquier cambio de arquitectura que dependa de equipos que no te reportan, puedes liderar su adopción sin autoridad —difundiendo en vez de ordenando, financiando con confianza, dando carriles en vez de puertas, discrepando sin bloquear, sosteniendo las conversaciones de carga, y construyendo el consenso que hace que la decisión se ejecute sola—. Dejaste de esperar que la razón se imponga por sí misma y empezaste a liderar la adopción, que es el trabajo real del arquitecto: no diseñar el sistema, sino lograr que la organización lo construya.

Hacia dónde sigues, dentro de esta guía:

• Módulo 5 — Stakeholders y atributos de calidad. Ya sabes liderar a los equipos; el módulo 5 te enseña a hablar con el otro lado —el negocio—: traducir metas como "queremos crecer 10x" o "no podemos caernos en Black Friday" en atributos de calidad (scalability, availability), manejar al stakeholder no técnico, explicar el trade-off en su idioma ("más disponibilidad = más dinero"), y saber decir no. Si este módulo fue sobre influir hacia abajo y a los lados (los equipos), el que sigue es sobre traducir hacia arriba (el VP) —la otra mitad del arquitecto que se mueve entre el código y el negocio—.

Y hacia el resto del ecosistema: cada vez que este módulo habló de "estándar", "guardrail", "contrato" o "ADR" sin re-enseñarlos, se apoyaba en las guías que sí los enseñan —architecture-decisions-and-tradeoffs, api-design-and-integration, architectural-styles-and-boundaries—. Ahora tienes lo que ninguna de ellas cubre: el liderazgo técnico sin autoridad, la habilidad social que decide si esas decisiones técnicas se adoptan o se quedan en un documento. La lección del módulo, en una frase: la arquitectura no la construye el que tiene razón; la construye el que logra que un grupo de gente que no le reporta haga suya una decisión —y esa es la palanca más grande y más difícil del oficio—.

Recursos

• Will Larson — Staff Engineer — el cierre natural del módulo: el manual del ingeniero de alto nivel que lidera sin ser manager, con relatos reales de rollouts de estándares y decisiones técnicas conseguidas por influencia. Exactamente lo que hiciste en este proyecto.
• Gregor Hohpe — The Software Architect Elevator — el arquitecto como la persona que conecta el negocio y los equipos moviéndose entre niveles, liderando sin autoridad; el marco que sostiene el módulo entero y anticipa el siguiente (hablar con el stakeholder).
• L. David Marquet — Turn the Ship Around! — el líder que multiplica dando intención en vez de órdenes; el ejemplo extremo de que liderar es habilitar, no mandar, que resume la actitud de todo el módulo.
• Jeff Bezos — Carta a los accionistas de Amazon 2016 ("disagree and commit") — la herramienta que aparece en dos lecciones del módulo (discrepar y consenso); el ejemplo ejecutivo de cómo se toman decisiones rápidas sin sacrificar el desacuerdo honesto.