Reglas revisadas de liderazgo en ingeniería

• Resumen de cinco reglas de liderazgo en ingeniería, validadas y redefinidas durante el último año en un entorno de transición a herramientas de IA y crecimiento acelerado (hypergrowth), junto con casos reales de proyectos que las respaldan
• Las migraciones ahora pueden ser lideradas en un 95% por una sola persona en vez de por un equipo, y completarse en el 10% del tiempo anterior; cuanto menor es el costo inicial, mayor es la influencia del juicio individual
• El código de primera pasada es casi gratis, pero el costo del código que realmente funciona depende del harness de desarrollo —pruebas, CI/CD, etc.—, así que no es gratis
• En la mayoría de los procesos, el caso base puede automatizarse por completo con agentes, y la primera pasada de revisión de código también puede hacerla un buen harness más rápido y mejor que una persona
• Para obtener de verdad los beneficios de la IA, se necesitan como condición previa equipos estables con contexto de dominio y toma de decisiones rápida y sólida

---

Contexto

• Trabajó entre inicios de 2014 y fines de 2020 en un entorno de hypergrowth, y el mayor valor de ese contexto era que los errores se hacen visibles el mes siguiente, no el próximo año (si te mueves rápido, los problemas explotan a gran escala)
• La razón por la que volvió a pensar recientemente en hypergrowth es la rápida expansión del negocio en Imprint, las contrataciones masivas del año pasado y el hecho de que la transición a herramientas de IA cambió la velocidad a la que se puede trabajar
• Este texto resume tanto las reglas de liderazgo reformuladas como los proyectos concretos del último año que lo llevaron a creer en ellas

Reglas revisadas

1. Las migraciones pueden ser realizadas por individuos, no por equipos

• Incluso cambios grandes y complejos pueden ser propiedad en un 95% de una persona o un equipo que los lidera, y completarse en el 10% del tiempo comparado con antes
• Cuanto más bajo es el costo inicial, mayores son las recompensas o penalizaciones por la calidad de cada migración
  • Incluso defectos pequeños destruyen el modelo mental de software de los colegas que luego deben mantenerlo
• La influencia del juicio individual sobre la empresa es hoy mayor que nunca

2. El código de primera pasada es casi gratis, pero el costo del código funcional depende del harness de desarrollo

• Vivimos en una época en la que todo el mundo debería poder escribir código, pero escribir código que funcione bien evitando casos límite desordenados sigue siendo difícil
• Esa dificultad depende del harness de desarrollo: pruebas, CI/CD, entornos de validación, vista previa de cambios, etc.
• Incluso en una empresa donde “todos programan”, lo importante no es que el equipo de marketing reduzca por sí mismo la asignación de servidores, sino si existen límites que les permitan participar de forma segura (similar a productos SaaS que permiten personalización mediante software)
• Las cosas que hace dos años eran las más valiosas para acelerar la velocidad de ingeniería siguen siendo las más valiosas hoy

3. Optimizar el caso base de los procesos para agentes

• Si hay un harness adecuado, control, contexto de dominio y buen juicio por parte del diseñador, se puede automatizar por completo el caso base de la mayoría de los procesos
• El caso base de la revisión de código hecha por personas es más lento y menos efectivo que la revisión de código de un buen harness
  • El harness se equivoca, pero las personas también; en la mayoría de las áreas, los cambios son relativamente seguros
  • Sin embargo, algunas áreas de alto riesgo son la excepción, y si se identifica bien esa distinción se puede avanzar más rápido sin riesgo; si se falla, aparecen innumerables problemas
• Como corolario, procesos de planificación como sprints semanales o quincenales operan a una altitud demasiado baja, y la planificación colaborativa entre personas debería darse en un nivel más alto

4. Los equipos estables y de alta responsabilidad (high ownership) con contexto de dominio son aún más importantes

• Lección aprendida en Uber: los equipos estables y sólidos producen resultados casi mágicos al acumular contexto de dominio, formar compañerismo y desarrollar un fuerte sentido de propiedad
• Incluso en una era donde el costo de ejecutar es bajo, sigue habiendo que hacer lo correcto, y eso apenas se ha vuelto un poco más fácil, no mucho más
  • Ejemplo: no se estaba recopilando en absoluto la información necesaria para optimizar producción, así que la solución propuesta por el harness era razonable pero incorrecta; la única solución real era instrumentar la información faltante
• Rechaza la idea de que una empresa AI-first puede operar solo con unos pocos ingenieros geniales; incluso personas con gran criterio chocan con los límites de la falta de contexto de dominio, así que el equipo estable sigue siendo la unidad fundamental

5. La toma de decisiones rápida, buena y sólida es condición previa para beneficiarse de la IA

• Para reemplazar una revisión legal por automatización, el equipo Legal debe poder comprometerse con ese cambio, y eso depende de un diseño cuidadoso y de la disposición del equipo para colaborar
• Los beneficios del aumento en velocidad de ejecución solo son posibles cuando se pueden tomar decisiones rápidas, sólidas y buenas
• Esta es la razón principal por la que el rol promedio de un CTO se volvió mucho más técnico y menos burocrático que hace un año
  • A menudo es la única persona que puede tomar decisiones vinculantes cuando hay desacuerdos entre equipos, así que debe decidir de forma constante para mantener la velocidad
  • No se afirma que los ejecutivos sean mejores tomando decisiones, sino que, mientras estén alineados entre sí y respeten esas decisiones, una decisión ejecutiva vinculante tiene un poder excepcional

Casos reales de aplicación

Migraciones

• Hace un año se hacían despliegues manuales unas ~6 veces por semana → hoy se hacen 200 a 400 despliegues por semana; el número de ingenieros solo se duplicó, pero el crecimiento interanual fue de 20 a 30 veces, y dos personas del equipo de infraestructura realizaron el 90% de la reestructuración total del modelo de despliegue y operación de migraciones en dos meses
• El 1 de enero, ~25% usaba Claude Code o Cursor a diario → a fines de febrero ya era 100%; sin imposición de arriba hacia abajo, se redujo la fricción mejorando la calidad de las herramientas y conversando con quienes no las adoptaban; hoy casi todos los PR tienen su primer borrador hecho por el harness
• Se unificaron diversos métodos de configuración en dos mecanismos de configuración (uno para constantes de cliente/servidor que casi no cambian, y otro para valores por producto y de cambio frecuente), mediante proyectos independientes liderados por ingenieros individuales
  • Una persona ordenó la arquitectura → otra implementó la arquitectura de referencia → varias la aplicaron a otras áreas; algo que antes habría sido un proyecto de años se completó en menos de un trimestre, incluyendo una herramienta interna para que equipos técnicos y no técnicos gestionen valores
• El frontend multi-repo se integró en una arquitectura monorepo en aproximadamente un mes, con un 95% del trabajo liderado por un solo ingeniero frontend; se obtuvo un harness frontend compartido y se eliminó por completo la dependencia de hosting de paquetes npm, que era una fuente de fricción
• El código frontend, que en su mayoría no tenía tipos, fue llevado a una tipificación estática completa, trabajo realizado por un ingeniero durante varias semanas con una gran cantidad de tokens
• Para tener mejores valores por defecto de seguridad y despliegues más rápidos, se hizo una migración de npm a pnpm, realizada por un ingeniero dedicando algunas horas al día durante varios días

El costo del código funcional depende del harness de desarrollo

• Lanzar documentos de diseño o PR “por encima del muro” a ingenieros de otros equipos no da resultados; los PR y documentos de diseño mediocres (slop) son baratos, pero en realidad hacen daño
  • Requieren limpieza y corrección, y ese contexto termina contaminando al LLM, produciendo un resultado peor que comenzar desde cero
• Cuando un gerente valida directamente los cambios, revisa los dashboards después del despliegue y resuelve los problemas que aparezcan, la contribución de código del gerente es un gran éxito; de lo contrario, no produce un efecto positivo

Optimización del caso base de los procesos para agentes

• Todos los incidentes entrantes del equipo de operaciones de clientes se triagean con un harness que conoce equipos y tickets abiertos, y tiene acceso limitado al data warehouse para estimar impacto; así se resuelve más rápido un trabajo complejo, especializado pero poco interesante
  • Los casos límite siguen siendo triageados por personas, y solo se automatizan algunos pasos dentro del mismo flujo, sin cambiar el workflow humano
• La primera pasada de revisión de código la realiza el mismo harness que implementó el cambio, pero con el contexto de escritura reiniciado, para que las personas se enfoquen en feedback de mayor valor
• El trimestre pasado se desplegaron Claude Code y Cowork en toda la empresa; el equipo de fraude fue especialmente agresivo en reemplazar trabajo manual por automatización de primera pasada, automatizando la investigación inicial de ataques potenciales (incluida la atribución derivada de los propios datos)
• Se migró de Jira a Linear, fortaleciendo la infraestructura de workflows agent-first con un MCP más potente y mejor integración con Slack; está casi terminada la prueba alfa de un harness interno que trae issues desde Linear y los resuelve automáticamente

Equipos estables y de alta responsabilidad con contexto de dominio

• Cuando se unió, había personas talentosas rotando rápidamente entre áreas según el proyecto, lo que hacía a la organización muy reactiva; hoy hay pequeños equipos dedicados en todas las áreas importantes, con inversión sostenida, y esos equipos usan directamente nuevas técnicas de IA
• Tras el lanzamiento de SierraAI, el equipo siguió mejorándolo sin parar hasta llevarlo a un nivel realmente sobresaliente; un resultado que habría sido imposible sin un equipo dedicado y enfocado

Toma de decisiones rápida, buena y sólida

• El cambio en la forma de gestionar configuración fue polémico, por lo que hubo que explicar el enfoque repetidamente; el impacto era distinto para cada equipo y los beneficios solo aparecían a nivel de ecosistema (una persona configurando la configuración de todos los equipos), así que era difícil impulsarlo de abajo hacia arriba
• El rediseño del pipeline de CI/CD también fue polémico porque cambiaba el modelo mental de despliegue y release, obligando a separar explícitamente despliegue y release mediante feature flags
• La integración al monorepo web también fue una decisión polémica con opiniones divididas, y los beneficios de una decisión unificada eran grandes
• La adopción de SierraAI implicó discusiones difíciles frente a competidores y frente a la opción de no adoptarlo, y requirió la aprobación de ejecutivos para cerrar el debate entre funciones cruzadas

Cierre

• Los casos anteriores son solo algunos de los más representativos; además se hicieron muchos otros, y el alcance de lo que es posible sigue expandiéndose cada mes
• Los factores que frenan el avance no han cambiado mucho: desalineación organizacional, falta de claridad y arquitectura técnica deficiente