El Peso de las Decisiones Técnicas
Todo sistema de software es el producto de miles de decisiones técnicas, desde pequeñas (convenciones de nomenclatura, elección de librerías) hasta grandes (selección de base de datos, arquitectura de servicios, diseño de API). Como Tech Lead, eres responsable de asegurar que estas decisiones se tomen bien. Esto no significa que tomes cada decisión tú mismo; significa que aseguras que el proceso correcto, las personas correctas y la información correcta estén involucrados para el nivel de impacto de cada decisión.
Las malas decisiones técnicas son costosas. Una elección equivocada de base de datos puede costar meses de trabajo de migración. Una arquitectura excesivamente compleja puede ralentizar al equipo durante años. El objetivo no es tomar decisiones perfectas (imposible con información incompleta) sino tomar decisiones suficientemente buenas a la velocidad correcta con mecanismos para corregir el rumbo.
Marcos de Decisión
Puertas de Un Solo Sentido vs Dos Sentidos
Amazon popularizó este marco: una decisión de un solo sentido es difícil o imposible de revertir (elegir una base de datos primaria, definir un contrato de API pública). Una decisión de dos sentidos es fácilmente reversible (elegir una librería interna, seleccionar un framework de UI para una herramienta de admin). Aplica rigor proporcional:
- Puertas de un solo sentido: Requieren análisis exhaustivo, proceso de RFC, múltiples revisores y documentación clara
- Puertas de dos sentidos: Pueden tomarse rápidamente por el ingeniero más cercano al problema, con documentación ligera
El Mayor Error en la Toma de Decisiones
Tratar las decisiones de dos sentidos como si fueran de un solo sentido. Esto lleva a la parálisis por análisis, donde los equipos pasan semanas debatiendo decisiones que podrían tomarse en una tarde y revertirse si resultan incorrectas. Como Tech Lead, tu trabajo a menudo es identificar que una decisión es de dos sentidos y dar al equipo permiso para moverse rápido.
El Marco DACI
Para decisiones importantes, usa DACI para clarificar roles:
Roles DACI
| Rol | Definición | Ejemplo |
|---|---|---|
| Driver | Lidera el proceso, recopila input, redacta la propuesta | El ingeniero que identificó la necesidad del cambio |
| Approver | Tiene la autoridad final de decisión | Tech Lead o Staff Engineer |
| Contributors | Proporcionan input y experiencia | Ingenieros relevantes, SREs, equipo de seguridad |
| Informed | Necesitan conocer el resultado | Equipos dependientes, product managers |
El Proceso de RFC
Un Request for Comments (RFC) es un documento escrito que propone un cambio técnico significativo, explica el razonamiento, considera alternativas e invita retroalimentación del equipo y la organización. Los RFCs son una de las herramientas más efectivas para tomar decisiones técnicas de alta calidad.
## Plantilla de RFC
### Título
Breve descripción del cambio propuesto
### Estado
Borrador | En Revisión | Aceptado | Rechazado | Reemplazado
### Contexto
¿Qué problema estamos resolviendo? ¿Cuál es el estado actual?
### Propuesta
Descripción detallada de la solución propuesta.
Incluir diagramas, contratos de API, modelos de datos según sea necesario.
### Alternativas Consideradas
¿Qué otros enfoques fueron evaluados?
¿Por qué fueron rechazados?
### Riesgos y Mitigaciones
¿Qué podría salir mal? ¿Cómo mitigamos cada riesgo?
### Plan de Migración
¿Cómo pasamos del estado actual al estado propuesto?
¿Cuál es el plan de rollback?
### Preguntas Abiertas
¿Qué aún necesita resolverse?
### Decisión
[Se completa después de la revisión]
Resultado y justificación de la decisión.Construyendo Consenso
El consenso no significa acuerdo unánime. Significa que todos han sido escuchados, las preocupaciones han sido abordadas (o explícitamente reconocidas) y el equipo puede comprometerse con la decisión incluso si individuos hubieran preferido un resultado diferente. Como Tech Lead, tu rol en la construcción de consenso incluye:
- Crear espacio para el disenso: Pregunta activamente "¿Qué podría salir mal?" y "¿Alguien está en desacuerdo?" El silencio no es acuerdo.
- Separar opiniones de datos: Cuando los debates se calientan, redirige a criterios medibles y evidencia.
- Establecer un plazo de decisión: Las discusiones sin final definido se prolongan. Establece una fecha para cuando la decisión se tomará.
- Discrepar y comprometerse: Una vez que se toma una decisión, todos la apoyan públicamente, incluso aquellos que argumentaron por alternativas.
- Documentar la decisión: Escribe qué se decidió, por qué y qué alternativas se consideraron (esto es un ADR).
Cuándo Decidir Tú vs Delegar
No todas las decisiones necesitan discusión grupal. Usa esta heurística:
- Decide tú mismo: Cuando tienes experiencia clara, la decisión es urgente y el riesgo es bajo a moderado
- Consulta y luego decide: Cuando necesitas input de otros pero retienes la autoridad final (la mayoría de decisiones arquitectónicas)
- Delega: Cuando alguien del equipo está más cerca del problema y tiene experiencia suficiente (la mayoría de decisiones de implementación)
- Facilita el consenso: Cuando la decisión afecta a múltiples equipos o tiene implicaciones a nivel organizacional
Indicadores de Calidad de Decisión
- Reversibilidad: ¿Podemos cambiar de rumbo si esto resulta incorrecto? Prefiere opciones reversibles.
- Tiempo al valor: ¿Qué tan rápido entrega beneficio? Prefiere la entrega incremental.
- Capacidad del equipo: ¿El equipo tiene las habilidades para ejecutar? Una solución elegante que el equipo no puede mantener es peor que una simple que sí pueden manejar.
- Costo de mantenimiento: ¿Cuál es el costo continuo de esta elección en complejidad, infraestructura y carga cognitiva?
- Alineación: ¿Esto nos acerca a nuestra visión técnica a largo plazo o crea divergencia?
Anti-patrones Comunes de Decisión
- HiPPO: La Opinión de la Persona Mejor Pagada gana, sin importar la evidencia. Combátelo requiriendo datos y propuestas escritas.
- Parálisis por análisis: Evaluar opciones interminablemente sin comprometerse. Establece plazos para las decisiones.
- Decisiones no documentadas: Decisiones tomadas en conversaciones de pasillo sin registro. Lleva a revisitar los mismos debates. Siempre documenta.
- Diseño por comité: Intentar incorporar las preferencias de todos lleva a soluciones infladas y comprometidas. Ten un tomador de decisiones claro.
- Falacia del costo hundido: Continuar con una mala decisión por la inversión previa. Evalúa decisiones basándote en el valor futuro, no en el costo pasado.