Plan de 30/60/90 días de un CTO fraccional para startups austriacas

Ha contratado a un CTO fraccional. ¿Qué deberían producir realmente los primeros 90 días? Los días 0 a 30 son para evaluar y estabilizar: una ronda de escucha, acompañar el trabajo real, una triación de riesgos y solo quick wins de bajo riesgo, que terminan en una evaluación escrita del estado de la ingeniería. Los días 31 a 60 son para planificar y sentar las bases: una hoja de ruta técnica ligada a los objetivos de negocio, un plan de contratación, una cadencia de entrega, métricas básicas de ingeniería y resolver el uno o dos riesgos principales. Los días 61 a 90 son para ejecutar y quedar listo para el traspaso: entregar algo a través de la nueva cadencia, reportar al consejo en términos de riesgo e inversión, y dejar la organización lista para funcionar sin la presencia diaria del CTO. El valor de un CTO fraccional no es ser la persona técnicamente más inteligente de la sala. Es un conjunto de artefactos y un sistema en marcha que sobreviven a su salida.

Este es el plan de ejecución. Para saber si conviene contratar uno y cuánto cuesta, consulte cuándo contratar a un CTO fraccional en Austria y el desglose de tarifas diarias. Este artículo responde a la siguiente pregunta: ahora que hay uno en la empresa, ¿qué ocurre?

El único principio que da forma a los 90 días

El mayor error que puede cometer un nuevo líder técnico es desmantelar los sistemas de ejecución actuales antes de tener una alternativa que funcione. Una startup que entrega, aunque sea de forma desordenada, vale más que una congelada a mitad de una reorganización. Por eso el plan adelanta la comprensión y posterga el cambio. El primer mes es sobre todo escuchar; el cambio real solo empieza una vez que el líder entiende de verdad cómo funciona el lugar.

Días 0 a 30: evaluar y estabilizar

El modo aquí es esponja, no excavadora. Reúnase con todos uno a uno (en un equipo de menos de 30 personas, literalmente con todos) y haga dos preguntas: qué cambiaría, y qué funciona tan bien que no debemos romperlo bajo ningún concepto. Acompañe el trabajo real: siéntese con los tickets de soporte, observe un incidente y entregue usted mismo un cambio trivial para sentir el pipeline de despliegue. En paralelo, ejecute una triación de riesgos que se convierte en el primer artefacto: seguridad, puntos únicos de fallo, riesgo de persona clave y factor autobús, costes de infraestructura y cuellos de botella de entrega. Tome solo quick wins de bajo riesgo y reversibles, del tipo que gana confianza sin apostar la empresa.

Lo que un buen CTO fraccional deliberadamente no hace en el primer mes: nada de reescrituras, nada de reorganizaciones, nada de revisiones de procesos y nada de despidos, con la única excepción de una amenaza real de seguridad. Quien propone una reescritura desde cero en la segunda semana le está mostrando una señal de alarma, no liderazgo.

Días 31 a 60: planificar y sentar las bases

Ahora empieza el cambio, pero en experimentos acotados, no en un big bang. Ejecute como mucho uno o dos cambios con plazo definido para que el equipo no se sature. Produzca la hoja de ruta técnica priorizada que liga el trabajo de ingeniería al runway y a los objetivos de producto. Si hay que contratar, escriba un plan enfocado para como mucho unos pocos puestos clave, porque el reclutamiento tiene un coste fijo por puesto y diez vacantes abiertas son su propio fracaso. Establezca la cadencia de entrega: sprints, standups, revisión de código y una definición clara de hecho. Ponga en marcha métricas básicas de ingeniería (las cuatro métricas DORA son el punto de partida habitual). Y resuelva el uno o dos riesgos principales del registro, capturando las decisiones de arquitectura y de proveedores como decision records sobre la marcha.

Días 61 a 90: ejecutar y quedar listo para el traspaso

Entregue algo real a través de la nueva cadencia, para que el cambio quede demostrado, no solo anunciado. Establezca un informe periódico a los fundadores o al consejo que hable en las dos monedas que un consejo realmente piensa: riesgo e inversión, no story points. Finalice los decision records y el runbook. Y haga lo que define un encargo fraccional: deje la organización lista para funcionar sin el CTO en la sala cada día. Una autoprueba útil al día 90 es si puede decir qué distingue a cada persona del equipo; si no puede, no ha tenido las conversaciones adecuadas. Por último, anote las métricas de éxito y el detonante que le dirá que es hora de contratar a un CTO a tiempo completo.

Los artefactos que deja un buen CTO fraccional

Esta es la diferencia entre un encargo real y una presencia cara en Slack. Exíjalos.

Un CTO fraccional que le deja un equipo que funciona y estos documentos ha hecho el trabajo. Quien le deja buenas sensaciones y un historial de chat, no.

Cómo medirlos, y las anti-métricas

Mida la previsibilidad de la entrega con las cuatro métricas DORA (frecuencia de despliegue, lead time de cambios, tasa de fallo de cambios y tiempo de restauración del servicio), el número de riesgos cerrados del registro, la velocity y la moral del equipo como tendencias en lugar de absolutos, los puestos cubiertos frente al plan, y la más subestimada: cuánto tiempo del fundador se liberó porque el fundador ya no es la ruta de escalado de cada decisión técnica.

No mida líneas de código. Premia el volumen sobre el valor, y borrar código a menudo es la victoria. El ingeniero del Lisa que reportó menos 2.000 líneas de código en un formulario de productividad, tras hacer el software más rápido y más pequeño, lo tenía exactamente bien. Y desconfíe de un CTO cuyo plan es una reescritura desde cero; reescribir software que funciona desde cero es uno de los errores estratégicos clásicos, porque es más difícil leer código que escribirlo, y el código viejo arrastra años de bugs ya corregidos.

"A un CTO fraccional se le contrata para volverse innecesario según un calendario. El entregable no es su presencia en reuniones. Es un equipo que entrega sin él y el puñado de documentos que permiten a la siguiente persona retomar donde lo dejó."

Cuándo reemplazar a un CTO fraccional por una contratación a tiempo completo

El detonante es cuando gestionar la ingeniería se convierte en un trabajo a tiempo completo. En la práctica, eso ronda el punto en que una sola persona ya no puede sostener al equipo dentro de un rango de control sano, aproximadamente la marca de ocho o más ingenieros, y en que alguien dedica más de media semana a gestionar en lugar de construir. Combinado con haber superado el product-market fit y necesitar ejecución diaria sostenida, esa es la señal para internalizar el rol. Cubrimos el coste y el momento en cuándo contratar a un CTO fraccional en Austria, así que aquí el foco es el traspaso, no las cuentas.

Haga la transición como un relevo lento, no como un corte limpio. El CTO fraccional escribe la descripción del puesto y filtra a los candidatos para su propio reemplazo, dirige una transferencia de conocimiento estructurada y traspasa el conocimiento sobre las personas junto con los sistemas. Aquí es exactamente donde los artefactos rinden: los decision records, la hoja de ruta y el runbook son el paquete de traspaso. El nuevo CTO a tiempo completo es dueño de las decisiones desde el día uno, y el fraccional se retira a un rol de asesoría o se va del todo.

La perspectiva austriaca

El encargo es casi siempre un retainer business-to-business, no un empleo, estructurado como un freier Dienstvertrag (contrato de servicios autónomo continuado) o un contrato ordinario de autónomo para disponibilidad continua, o un Werkvertrag (contrato de obra) cuando hay un único entregable concreto. Eso lo mantiene libre de impuesto sobre nóminas y de obligaciones laborales, pero debe estructurarse para evitar el falso autónomo (Scheinselbstständigkeit), de modo que el CTO determine realmente su propio tiempo y medios. El mercado de ingenieros senior está tenso, sobre todo fuera de Viena, donde cubrir un puesto senior puede llevar muchos meses, lo cual es en parte por qué un líder que además sabe contratar bien resulta valioso. Y uno bueno conoce el mapa de financiación: los programas de aws financian la construcción de la empresa y la financiación semilla o de crecimiento, mientras que la FFG financia investigación y desarrollo genuinos. Así que la hoja de ruta y su documentación deberían estructurarse de modo que el trabajo de I+D se mapee limpiamente a la FFG y la construcción de la empresa a aws. Esa es una razón concreta, de dinero sobre la mesa, por la que la disciplina documental importa aquí.

¿Fraccional, interino, a tiempo completo o cofundador?

Para la fase de ejecución, la distinción que importa es simple: el interino es a tiempo completo pero temporal, el fraccional es a tiempo parcial pero continuo.

Para una startup en fase temprana, en o justo antes del product-market fit, el CTO fraccional construye el sistema operativo; un interino tapa un hueco; y el tiempo completo o un cofundador responden a una pregunta distinta sobre permanencia y propiedad.