Software Architect · Módulo 20
El arquitecto rara vez puede simplemente dar una orden. Su influencia se sostiene en la claridad, la confianza, la calidad del reasoning y la capacidad de potenciar a los demás.
Influence · alignment · mentoring · principles
El liderazgo técnico es la capacidad de mejorar las decisiones del equipo, no la de tomar personalmente cada decisión.
Los principios escalan mejor que las opiniones
Las reglas de tránsito permiten que miles de conductores crucen las intersecciones sin pedirle permiso personal a un despachador en cada esquina.
Si el arquitecto responde cada pregunta a mano, se convierte en bottleneck. Si formula principios, quality gates y un decision framework, el equipo puede actuar por su cuenta.
Ejemplo de principio: "El domain layer no depende de la infrastructure". Eso es mejor que discutir en cada PR si se puede importar un ORM dentro de un use case.
La influencia requiere confianza
La gente sigue al navegador mientras lo lleve sin problemas. Una ruta segura pero equivocada daña la confianza por mucho tiempo.
La confianza se construye con precisión, disposición a reconocer la uncertainty, una descripción honesta de los trade-offs y respeto por el contexto del equipo. Un arquitecto que siempre "sabe más" pierde influencia rápido.
Una posición fuerte no suena como un absoluto: "Veo un riesgo alto en este data model, porque la migración afecta la external API y billing. Probemos una alternativa".
El arquitecto debe dejar detrás un equipo más fuerte, no un equipo dependiente de él.
Ejemplo: el architecture review como enseñanza
Un buen entrenador no juega el partido por el equipo. Ayuda a los jugadores a leer la cancha.
En el review, el arquitecto no dicta la respuesta — hace preguntas: cuáles son las invariants, dónde vive la idempotency, cómo migramos, qué pasa en partial failure, qué métricas van a mostrar éxito. El equipo mismo afina el diseño y registra el ADR.
La próxima vez, el equipo va a hacer algunas de esas preguntas sin el arquitecto en la sala.
Antiejemplo: el arquitecto-héroe
Si un puente se mantiene en pie sólo porque una persona ajusta los bulones a mano todos los días, eso no es un puente confiable.
El arquitecto resuelve personalmente cada problema difícil, escribe las partes más importantes, se acuerda de cada decisión y no delega nada. Desde afuera parece eficiente. Adentro genera bus factor y learned helplessness.
El liderazgo real reduce la dependencia de una sola persona.
- ¿Qué decisiones puede tomar el equipo sin mí? - ¿Qué principios reemplazan discusiones recurrentes? - ¿A quién enseñé architectural reasoning el último mes? - ¿Dónde se convirtió mi participación en bottleneck?