Equipos que sostienen lo que construyen
La mayoría de los equipos que encuentro no tienen un problema de talento: tienen un problema de criterio compartido. Cada persona decide bien por su cuenta y el conjunto avanza en direcciones ligeramente distintas, hasta que integrar cuesta más que construir. Eso no se arregla con una herramienta nueva ni con más reuniones; se arregla haciendo explícito lo que hasta ahora vivía en la cabeza de dos o tres personas.
Entro al código, no como una capa de gestión encima del equipo. Abro el repositorio, escribo en él y reviso pull requests con el mismo detalle con el que reviso los míos; y cuando hace falta asumo el liderazgo técnico del frente, que es exactamente lo que hice dirigiendo Pagos y Finanzas en Yummy. El criterio queda escrito —especificaciones, ADRs, estándares que se pueden discutir y cambiar— y practicado, en revisiones donde se explica el porqué y no solo el qué. El objetivo declarado de cada acompañamiento es volverse innecesario: si a los seis meses el equipo sigue dependiendo de mí para avanzar, hice mal el trabajo.
Trabajo especialmente bien con equipos de plataforma y de pagos, donde una decisión de diseño equivocada no produce un bug visible sino una discrepancia contable que aparece un trimestre después. En esos contextos el liderazgo técnico no es motivacional: es la disciplina de escribir lo que se va a construir antes de construirlo.
- Formato
- Acompañamiento
- Alcance
- 15 personas
- Eficiencia
- +40%
- Entrega
- −60%
¿Qué involucra?
- 01Revisión de código en profundidad, con el porqué escrito
- 02Mentoría uno a uno a desarrolladores junior y semi-senior
- 03Establecimiento de estándares técnicos y guía de estilo
- 04Especificación y ADRs antes de escribir código
- 05Optimización de procesos de desarrollo y entrega
¿Cómo se aborda?
Paso 01
Diagnóstico del sistema y del equipo
Reviso el repositorio, el pipeline y el tablero antes que las personas. El código dice cómo se decide de verdad: dónde hay pruebas, dónde hay parches, qué se toca con miedo. De ahí sale un mapa de riesgos técnicos ordenado por lo que cuesta si falla, no por lo que molesta.
Paso 02
Spec-Driven Development como norma
Antes de escribir código se escribe la especificación: qué problema resuelve, qué invariantes debe mantener, qué queda explícitamente fuera. SDD parece burocracia hasta que evita la tercera reimplementación de la misma regla de negocio. Cada decisión estructural queda además como ADR fechado, así que dentro de un año se sabrá por qué se hizo así.
Paso 03
TDD donde el costo del error es alto
No pido cobertura por cobertura. Pido pruebas donde el dinero cambia de manos: cálculo de comisiones, conciliación, idempotencia de reintentos. Ahí el test se escribe primero, porque es la única forma de saber que la regla quedó entendida antes de codificarla. En el resto, pruebas de contrato e integración que sí atrapan regresiones reales.
Paso 04
Ceremonias que producen especificación
El kickoff se transcribe y produce un borrador; el refinamiento lo convierte en especificación aprobada. Suena a proceso añadido y en la práctica quita trabajo: elimina el acta que nadie escribe y la discusión que se repite dos semanas después.
Paso 05
Traspaso y medición
El acompañamiento termina con el equipo tomando decisiones sin mí, y eso se mide: tiempo de ciclo, tasa de fallo en despliegue, tiempo de recuperación. Son las métricas DORA, y sirven porque no se pueden actuar sin cambiar de verdad cómo se trabaja.
Del kickoff transcrito al punto de capacidad
Lo que se acuerda hablando en un kickoff se pierde. Dos semanas después nadie recuerda por qué se descartó la alternativa obvia, y la discusión se repite entera. La primera pieza del ciclo es simple: la reunión se transcribe y de ahí sale un borrador de especificación —qué se dijo, qué se decidió, qué quedó abierto—. No es la especificación final; es el acta que nadie iba a escribir.
Ese borrador entra a la ceremonia de refinamiento y ahí se corrige con el equipo. Es la parte que no se puede saltar y donde la regla es la de siempre: la IA prepara, el equipo decide. Se marcan los invariantes, se parte lo que es demasiado grande, se descarta lo que se coló mal transcrito. Lo que sale aprobado ya es una especificación de verdad.
A partir de ahí se ejecuta como Spec-Driven Development: la especificación es la fuente, el código la sigue, y cada decisión estructural queda como ADR fechado. La diferencia con SDD a secas es de dónde vino la primera versión — de una conversación real, no de un documento que alguien redactó a solas tres días después.
El ciclo cierra en git. Cada entrega deja una traza completa: especificación, commits, pull request, despliegue. Cuando eso se acumula durante unos meses hay un histórico que relaciona la forma de una especificación con lo que costó de verdad entregarla, por persona y según cuánto se apoyó en IA. De ahí salen dos cosas que normalmente se adivinan: los puntos de capacidad de una tarea, estimados contra casos parecidos que ya ocurrieron, y los KPIs de entrega —tiempo de ciclo, tasa de fallo en despliegue, tiempo de recuperación— calculados del mismo registro en lugar de reportados a mano.
- Kickoff transcrito → borrador de especificación con decisiones y preguntas abiertas
- Refinamiento con el equipo: la IA prepara, las personas deciden
- Especificación aprobada como fuente, ADR para lo estructural (SDD)
- Traza completa en git: especificación → commits → pull request → despliegue
- Capacidad estimada contra el histórico real, no contra la intuición
- KPIs y métricas DORA calculadas del registro, no reportadas a mano
¿Dónde lo he hecho?
- Yummy Inc. · Tech Leader
- Equipo de 7 desarrolladores en Pagos y Finanzas de una super-app de LATAM
- 7 personas
- Cencosud S.A. · Developer Lead
- Módulos de contabilidad con integración SAP y optimización de procesos batch
- −60% tiempo
- Sky Airline · Sr. Software Engineer
- Escalé hasta Tech Leader Backup mientras sostenía la versión anterior en producción
- 1M+ tx/mes
Las cifras vienen de sistemas en producción. La trayectoria completa está en Sobre mí.
Prácticas y entregables
Prácticas
- Spec-Driven Development
- Test-Driven Development
- Ceremonias de refinamiento
- Estimación contra histórico
- Trunk-based development
- Revisión de código en profundidad
- ADRs
- Métricas DORA
Entregables
- Mapa de riesgos técnicos priorizado
- Estándares de ingeniería y guía de estilo
- Plantillas de especificación y ADR
- Plan de formación por persona
- Métricas de entrega con línea base
- Ciclo kickoff → especificación → SDD instrumentado
Stack
- TypeScript
- Node.js
- React
- GitHub Actions
- spec-kit
Lo que suelen preguntarme
- ¿Esto es un Tech Lead fraccional?
- Puede serlo. Dirigí el equipo de Pagos y Finanzas de Yummy y antes lideré desarrollo en Cencosud, así que el rol no me es ajeno. Hoy soy Senior Software Engineer en Wenia, y en la práctica eso te conviene: el liderazgo técnico lo ejerzo desde el repositorio, revisando pull requests y escribiendo especificaciones, no desde una reunión de seguimiento. Cuando ya existe un Tech Lead interno, trabajo con él; cuando no, ayudo a identificar a quien pueda serlo.
- ¿Cuánto dura un acompañamiento?
- Entre tres y seis meses en la mayoría de los casos, con dedicación parcial. Menos de tres no alcanza para que un hábito nuevo se sostenga solo; más de seis suele significar que estoy tapando un problema de estructura en vez de resolverlo.
- ¿Trabajas con equipos que no son de pagos?
- Sí. Los hábitos —especificar antes de construir, probar donde duele, medir la entrega— son los mismos. Lo que cambia es dónde está el riesgo, y eso lo identifico en el diagnóstico.
- ¿La IA estima las tareas por el equipo?
- No estima: propone un rango contra tareas parecidas que ya se entregaron, con su traza en git. El equipo lo acepta o lo corrige en el refinamiento, y esa corrección también entra al histórico. Lo que se elimina es la estimación a ojo sobre una tarea que ya se hizo tres veces.
- ¿Qué necesitas del equipo para empezar?
- Acceso de lectura al repositorio y al pipeline, y una hora con quien conozca la historia del sistema. Con eso puedo decir en una semana dónde está el riesgo real.
Otros frentes
- Fintech y bancaDesarrollo e implementación de soluciones tecnológicas para el sector financiero y bancario.
- BackofficeAutomatización y optimización de procesos internos y operaciones de backoffice empresarial.
- ArquitecturaDiseño de arquitecturas de software escalables, resilientes y mantenibles para sistemas empresariales.
- Seguridad y complianceImplementación de soluciones de seguridad y cumplimiento normativo para sistemas financieros.
- Infraestructura cloudDiseño e implementación de infraestructuras cloud escalables, seguras y optimizadas en costos.
- Inteligencia artificialAgentes de IA aplicados a sistemas financieros y de backoffice, incluida la infraestructura para que operen dinero con límites y auditoría.