Cuando entré como CTO de una plataforma de eventos en directo a finales de 2022, el contexto era el habitual de muchos productos tras la pandemia: el equipo técnico se había reducido y rotado, parte del conocimiento del producto se había ido con las personas que se marcharon, y mientras tanto la plataforma seguía operando con tráfico diario alto y varios millones de usuarios registrados. No había opción de parar el producto durante meses para reorganizarse.
Tres años después de aquello, esto es lo que más me costó aprender — y lo que aplicaría sin pensarlo si tuviera que volver a hacerlo.
01Lo primero que descubres: el mapa que tenías está desactualizado
Una de las cosas más subestimadas de heredar un equipo técnico post-rotación es que la documentación que existe casi nunca coincide con el sistema real. No por mala fe — por entropía: los documentos se quedaron en el momento en que alguien tuvo tiempo de mantenerlos, y desde entonces el código siguió evolucionando sin ellos.
Las primeras semanas las pasé entendiendo qué era lo que de verdad había en producción, qué estaba documentado, qué solo vivía en cabezas que ya no estaban y qué hacía falta inferir leyendo código. Esa fase es lenta y se siente improductiva. Es la inversión más rentable que hice. Saltarla habría significado tomar decisiones sin contexto y romper cosas durante meses.
02La velocidad no se recupera contratando rápido
La tentación obvia cuando entras y el equipo no llega es contratar deprisa. Resistirla fue clave. Cada incorporación temprana mal pensada habría costado meses de onboarding poco productivo y, peor, habría diluido la atención en el equipo que sí estaba.
La secuencia que funcionó:
- Primero, estabilizar el equipo existente. Conversaciones uno a uno, entender qué estaba pasando, devolver claridad sobre dirección y prioridades. La velocidad de la gente que ya estaba subió antes de incorporar a nadie nuevo.
- Segundo, identificar las plazas críticas reales. No las que faltaban en el organigrama abstracto: las que de verdad estaban frenando producto. A veces era un Tech Lead, a veces era un perfil de QA, a veces era alguien con experiencia operativa concreta.
- Tercero, contratar despacio y bien. Procesos de selección con varias entrevistas técnicas, pruebas razonables, decisiones tomadas con varios miembros del equipo. Cada incorporación nos cargaba 6-8 semanas de onboarding antes de aportar; saltarse el rigor habría salido caro.
03El equipo absorbe la moral del CTO antes que sus decisiones técnicas
En contexto post-pandémico, donde había rotación reciente y desconfianza, la parte humana pesaba más que la técnica. Las decisiones técnicas son explicables; la confianza no. Pasé las primeras semanas más en uno-a-uno y conversaciones informales que en code reviews. Esa inversión cambia el comportamiento del equipo de forma visible: la gente vuelve a opinar abiertamente, vuelve a proponer mejoras, vuelve a sentir que el producto es suyo.
La regla que me quedé: en una reconstrucción, el CTO es ejecutivo de equipo antes que técnico jefe. Las semanas que dedicas a estabilizar el factor humano son las que devuelven velocidad técnica.
04No reescribir, evolucionar
La tentación arquitectónica al heredar un sistema imperfecto es proponer reescribirlo. Casi siempre es la salida equivocada. Una reescritura cuesta meses, abre frentes nuevos, multiplica los puntos de fallo y, mientras tanto, el negocio sigue dependiendo del sistema viejo. La probabilidad de éxito es baja y el coste de oportunidad es altísimo.
La decisión fue mantener el stack maduro (Vue, Django, PostgreSQL, AWS) y evolucionarlo donde el producto lo pedía. Optimizar queries críticas, añadir caché donde rendía, mejorar observabilidad, atacar deuda técnica priorizada por impacto. Ningún cambio espectacular; muchos cambios pequeños que se sumaron a meses de mejor velocidad y mejor calidad.
El test mental que aplicaba: "si esto sale mal, ¿el negocio se entera mañana o me da meses para corregirlo?". Las decisiones que cumplían el segundo criterio iban primero. Las que tocaban directamente al usuario iban con más cautela.
05El bus factor es el primer riesgo a mitigar
Cuando heredas un equipo con rotación reciente, el bus factor (qué pasa si X persona se va) suele ser bajo. Conocimiento crítico vive en cabezas, y las personas con esas cabezas no siempre se quedan. Esto no se arregla con documentación posterior — se arregla con prácticas que difunden el conocimiento mientras se trabaja.
- Pair programming en cosas estratégicas. No para todo el día a día, sino específicamente cuando alguien va a tocar un módulo donde solo él tiene contexto.
- Code reviews exigentes pero rápidas. No para "vetar", sino para difundir contexto. Cuanta más gente entiende cada módulo, menos depende de personas concretas.
- Documentación al hacer, no después. READMEs, ADRs, comentarios en módulos críticos. Todo escrito en el momento en que se diseña la decisión, no cuando ya nadie recuerda por qué.
- Onboarding estructurado para nuevos. Ruta clara primeras 2 semanas, mentor asignado, expectativas explícitas. Reduce el tiempo de productividad y el riesgo de marcha temprana.
06Errores que cometí (y que evitarías si tuvieras este post antes)
- Querer ir más rápido de lo que el equipo aguantaba. Las primeras semanas empujé más de la cuenta. Producir demasiado pronto generó cansancio que pagamos después en velocidad y en moral.
- Subestimar el tiempo de recuperar velocidad. Pensaba en 6-8 semanas; fueron 3-4 meses reales para que el equipo volviera a una velocidad estable. Plantear plazos honestos al negocio es mejor que plazos optimistas que no se cumplen.
- No invertir suficiente en observabilidad temprano. Pasamos un par de incidentes que se habrían detectado antes con dashboards específicos. Reordenar la inversión: observabilidad antes que features bonitas.
- Retrasar las decisiones difíciles de equipo. Cuando el encaje de alguien con el proyecto no funciona, esperar rara vez lo arregla: desgasta a esa persona y al resto. Aprendí a tener esa conversación antes, y a tenerla de frente.
07Lo que aplicaría si tuviera que repetirlo
Hoja de ruta para CTO que hereda un equipo
- Semanas 1-4: escuchar más que actuar. Conversaciones uno a uno, entender el sistema real, identificar palancas. Resistir la presión de "demostrar valor" con cambios visibles.
- Mes 2: estabilizar moral y dirección. Roadmap claro, prioridades visibles, apoyo activo a las decisiones que el equipo necesita tomar.
- Meses 3-4: contratar lo crítico, no más. Procesos rigurosos. Cada incorporación importa el doble cuando el equipo es pequeño.
- Meses 4-6: evolución técnica controlada. Atacar deuda priorizada, mejorar observabilidad, optimizar lo que el negocio necesita, sin tocar lo que funciona.
- Mes 6+: velocidad sostenida. A partir de aquí el equipo entrega de forma predecible. La ventaja competitiva de la reconstrucción es que el equipo nuevo conoce el sistema real, no el documentado.
08Para fundadores que están en este momento
Si estás en una situación parecida — equipo a reconstruir, plataforma operando, sin tiempo para parar — tres cosas que diría:
- Resiste el impulso de reescribir. Es casi siempre la salida equivocada cuando hay un sistema en producción que funciona aunque sea mal.
- Invierte en moral antes que en hiring. Un equipo estable de 5 personas produce más que un equipo de 8 con rotación constante.
- Plantéate si necesitas un CTO interno o un fractional para esta fase. En contextos de reconstrucción la dedicación full-time suele ser necesaria.
