El CTO fundador de una startup de 30 ingenieros sigue programando a tiempo completo. Las decisiones de arquitectura se acumulan en su cola, los seniors dejan de proponer cambios porque la revisión tarda días y la organización deja de evolucionar porque nadie con mandato para dirigir la arquitectura la está dirigiendo.
Señales de que el cuello de botella eres tú
- Tus pull requests se quedan parados mientras el resto del equipo espera respuesta
- Los seniors ya dicen "Marc lo revisa después" y siguen con el trabajo a medias
- Una decisión técnica pesada se vuelve reunión porque solo tú tienes el contexto completo
- Ningún ingeniero del equipo explica toda la arquitectura a alguien recién llegado
Las cuatro señales apuntan a una misma causa: el rol del CTO cambió y tú sigues ejerciendo el de antes. Melvin Conway describió en "How Do Committees Invent?" (Datamation, 1967) que el diseño de un sistema refleja la comunicación de quienes lo construyen. Con una persona en el centro de cada decisión, todo diseño pasa por ella y envejece al ritmo de ella.
El trabajo que queda con el CTO
Tres frentes quedan sin dueño mientras tú estás en el editor: la dirección técnica de los próximos 18 meses, con los trade-offs que entran y los que quedan fuera; la formación de gente técnica capaz de asumir decisiones que hoy pasan por ti; y el encaje entre la estrategia de ingeniería y las metas de producto.
Andrew Grove mide el trabajo de un gestor por lo que la organización sostiene sin él, en High Output Management (Vintage, 1985). El código que dejas para ti es la menor de las palancas que tienes. Marty Cagan describe en Empowered (Wiley, 2020) equipos de producto que deciden cerca del trabajo cuando la dirección fija rumbo y límites. Sin ese movimiento, el equipo te espera en el código y en la dirección al mismo tiempo.
Transición de 90 días
Días 1 a 30. Transfiere un dominio a la vez, empezando por el que menos depende de ti. Saca de tu camino las dependencias críticas: quién aprueba el deploy, quién maneja la guardia, quién revisa el módulo de pagos.
Días 31 a 60. Reduce el code review a los cambios que alteran contratos entre módulos. Reserva dos días de la semana para contribución técnica y baja la frecuencia cada dos semanas.
Días 61 a 90. Deja de hacerlo cuando la organización responda sin ti en el código. Si una decisión vuelve a ti dos veces en la misma semana, ese dominio sigue contigo.
De qué tienes miedo
Perder relevancia, ver a alguien fallar donde tú no fallarías, quedarte lejos de las herramientas. Todo fundador técnico cruza esos tres. El costo de quedarse aparece en semanas de decisiones trabadas y en un equipo que no entrenó a nadie para ocupar tu lugar.
Lo que vuelve después
Entre tres y seis meses, las decisiones que esperaban por ti avanzan sin reunión, dos ingenieros conducen las revisiones de arquitectura solos y recuperas días completos para pensar en la dirección. Dos semanas de vacaciones después, los pull requests siguen aprobados y la guardia tiene dueño.
