Cuándo contratar un CTO y cuándo no hace falta

Fundador de startup planificando arquitectura técnica en pizarra antes de contratar un responsable de tecnología

La mayoría de las veces que nos llega esta pregunta, la respuesta corta es «todavía no». Y la larga es más incómoda: lo que falta no es un CTO, es alguien que escriba código a las tres de la tarde de un martes sin que haya que explicarle el negocio tres veces. Son dos problemas distintos. Confundirlos cuesta meses de búsqueda y un salario que tu runway no sostiene.

Hace un par de años revisamos los doce últimos proyectos que habían pasado por nuestras manos con esa duda encima de la mesa, exactamente para responder a cuándo contratar un CTO y cuándo no hace falta. En nueve de ellos, el fundador estaba convencido de necesitar un responsable técnico máximo a jornada completa. En tres lo necesitaba de verdad. Los otros seis tenían un problema de capacidad de ejecución, no de mando.

Vamos a desmontarlo escenario por escenario, porque no existe una regla única: existe tu situación concreta y un umbral bastante identificable.

La pregunta previa: ¿te falta dirección técnica o te falta ejecución?

Un CTO hace falta cuando existen decisiones tecnológicas caras de revertir, un equipo de más de cinco personas que nadie coordina o un modelo de negocio cuya ventaja vive dentro del código. No hace falta cuando el producto cabe en la cabeza de una persona y el problema real es que hay trabajo pendiente y pocas manos para sacarlo.

¿Qué te quita el sueño exactamente? Si la respuesta es «vamos lentos, hay tres cosas pendientes y nadie las saca», tienes un problema de manos. Si la respuesta es «hemos construido algo que no sé si aguanta, no sé a quién contratar después y no sé si la decisión de base de datos que tomamos en enero nos va a explotar en la cara», entonces hablamos de otra cosa.

Nosotros usamos una prueba tonta pero eficaz. Coge las cinco decisiones técnicas más caras de revertir que tengas pendientes este trimestre. ¿Puedes describirlas? ¿Sabes qué se juega en cada una? Si has escrito cinco, necesitas liderazgo. Si te has quedado en dos y las dos eran «elegir proveedor de pagos», no.

Lo que pasa es que el mercado empuja en dirección contraria. Suena mejor decirle a un inversor que has incorporado a un responsable máximo de tecnología que decirle que has fichado a dos seniors y a un arquitecto por horas. Total, que se contrata el título antes que la función. Y el título no arregla backlogs.

Tres síntomas que se disfrazan de falta de liderazgo

Los deadlines que se incumplen de forma sistemática suelen ser un problema de estimación y de alcance, no de mando. Cambia la persona al mando y seguirán incumpliéndose.

La rotación en el equipo técnico se achaca al vacío de mando con demasiada facilidad. En los cuatro casos que hemos visto de cerca, la causa era salarial en dos, de producto sin foco en uno, y sí, de liderazgo inexistente en uno.

Y la deuda técnica acumulada. Esta es la más traicionera: puede ser una señal legítima de que nadie está protegiendo la salud del sistema, o puede ser simplemente el precio razonable de haber ido rápido en un MVP. Depende de si te impide vender o solo te incomoda.

Si tu producto todavía cabe en la cabeza de una persona

Aquí somos bastante rotundos: no abras esa vacante.

Mientras el sistema completo pueda ser explicado por una sola persona en cuarenta minutos ante una pizarra, la coordinación no es tu problema. Y la función principal de esa figura senior es, en el fondo, coordinar: gente, decisiones, riesgos y horizontes temporales de dieciocho meses. Si no hay nada que coordinar, pagas por una capacidad que no vas a consumir.

Señales inequívocas de que todavía no toca:

  • Menos de cinco personas técnicas en nómina.
  • El sistema se explica entero en una pizarra.
  • Ninguna decisión pendiente es irreversible.
  • El ingreso no depende del software propio.
  • No hay contrataciones técnicas previstas.
  • El backlog está lleno, no ambiguo.

Recuerdo un caso de 2022 que nos dejó tocados. Una plataforma de gestión para clínicas, dos fundadores, uno de ellos técnico razonablemente competente. Insistieron en incorporar un responsable máximo de tecnología a jornada completa antes de tener cuarenta clientes. El perfil que entró era bueno de verdad: venía de escalar un equipo de quince developers. A los cinco meses se fue, aburrido. No había equipo que escalar. Había que programar.

Si aplicaras el mismo dinero a un senior de producto con buen criterio de arquitectura, probablemente avanzarías el doble. Lo hemos medido en nuestra propia cartera: en fase pre-encaje, el retorno por euro invertido en capacidad de ejecución supera con holgura al de capacidad de decisión. No es una ley universal, pero se repite demasiado como para ignorarlo.

Cuando el equipo técnico pasa de cinco y nadie decide el rumbo

Cinco. Ese es el número que nos sigue apareciendo.

Por debajo de cinco personas técnicas, un lead senior con algo de mano izquierda sostiene la estructura. Por encima, empieza a pasar algo curioso: el tiempo que cualquiera dedica a coordinar crece más rápido que el equipo. Con seis o siete personas, alguien está gastando ya un treinta por cien de su jornada en desatascar dependencias, revisar criterios y decidir qué no se hace. Si ese alguien eres tú y además llevas ventas, tienes un problema estructural.

Señales concretas de que has cruzado el umbral: dos personas resuelven el mismo problema de formas incompatibles y nadie lo detecta hasta el merge; la decisión sobre infraestructura lleva tres semanas parada porque nadie se siente autorizado a tomarla; los nuevos incorporados tardan más de seis semanas en ser productivos porque no hay criterio escrito de nada.

El momento en que nos equivocamos con este umbral

Durante bastante tiempo defendimos que el número mágico eran ocho personas. Lo decíamos con seguridad. Después de acompañar varios equipos en esa transición, vimos que el deterioro empezaba antes, alrededor de cinco o seis, y que a los ocho ya habías perdido dos trimestres. Cambiamos el criterio: mejor incorporar a esa figura un poco antes de necesitarla que tres meses tarde. El coste del adelanto es dinero; el coste del retraso es producto roto y gente quemada.

Equipo de desarrollo de seis personas discutiendo prioridades técnicas en una reunión de trabajo

Cuando la tecnología es el negocio, no un soporte del negocio

Existe un escenario en el que todo lo anterior se cae: cuando la ventaja competitiva vive dentro del código.

Un marketplace que compite por catálogo y por marca puede funcionar años con tecnología correcta y aburrida. Una empresa cuyo diferencial es un motor de scoring, un sistema de sincronización en tiempo real o un modelo entrenado con datos propios, no. Ahí la arquitectura es la estrategia, y delegar la estrategia en un proveedor externo o en un lead sin asiento en las decisiones de negocio es, digámoslo suave, valiente.

En estos casos, un CTO con equity y voz en el comité no es un gasto de estructura: es la persona que decide qué se puede prometer a un cliente y qué no. Y esa decisión se toma varias veces por semana.

Hay un test rápido. Si tu principal riesgo de los próximos dieciocho meses es comercial, el liderazgo tecnológico puede esperar. Si tu principal riesgo es «no sabemos si esto se puede construir y mantener a este coste», no puede.

El caso híbrido, que es el más frecuente

Mucha empresa está a mitad de camino: la tecnología no es el producto entero, pero tampoco es un accesorio. Software de gestión vertical, herramientas internas convertidas en producto, integraciones complejas con sistemas de terceros. Para este grupo, nuestra recomendación habitual es una fórmula parcial, que es de lo que va la sección siguiente.

Si lo que aprieta es un hito concreto: fractional, interim o asesor

Y aquí viene lo bueno, porque es la opción que menos se explora y la que resuelve más casos.

Cuando la necesidad no es permanente sino atada a un evento (una due diligence técnica, una migración, una ronda, la selección de los tres primeros ingenieros, un rediseño de arquitectura antes de escalar), no necesitas un contrato indefinido. Necesitas criterio senior dos días por semana durante cuatro o seis meses. Eso es exactamente lo que resuelve un CTO externo con dedicación parcial, y por orden de magnitud aproximado suele situarse en varios miles de euros al mes según dedicación, frente a un paquete anual completo de cinco cifras altas más equity en la opción interna. Conviene pedir cifras concretas a cada proveedor: no hay una tarifa de mercado publicada y contrastable en España.

Modalidades que funcionan, con sus condiciones:

  • Fractional: dos o tres días semanales, de forma sostenida. Ideal en fase de equipo pequeño y decisiones frecuentes.
  • Interim: dedicación alta durante un periodo cerrado. Útil cuando hay un hueco que tapar tras una salida.
  • Asesor: cuatro o seis horas al mes, revisión y contraste. Solo sirve si ya hay alguien ejecutando bien dentro.

¿Cuál es la trampa? Que un perfil parcial no construye cultura de equipo, y que sin objetivos ni métricas claras acaba sin autoridad real dentro de la empresa. Si tu problema es que cinco personas no se hablan, alguien que aparece los martes no lo va a arreglar. Para eso hace falta presencia diaria. Lo hemos intentado y ha salido mal; conviene decirlo.

Cuándo basta con un VP of Engineering, un arquitecto o un lead senior

Mira, al final la mitad de las vacantes de dirección técnica que leemos describen, en realidad, otro puesto.

Si buscas a alguien que organice procesos, gestione personas, mejore el ciclo de entrega y monte una estructura de carrera técnica, estás describiendo a un VP of Engineering. Si buscas a alguien que decida cómo se construye el sistema y asuma las decisiones difíciles de arquitectura, es un arquitecto. Y si buscas a alguien que empuje el día a día de tres o cuatro personas, es un tech lead senior, cuyo coste está bastante por debajo del de un puesto de comité.

Perfil Resuelve No resuelve Umbral típico
Tech lead senior Ejecución diaria, calidad de código Estrategia de producto, hiring a escala 2-5 personas
Arquitecto Decisiones de sistema difíciles de revertir Gestión de personas Sistemas con integraciones complejas
VP of Engineering Procesos, organización, entrega Representación técnica ante inversores 10+ personas
Liderazgo tecnológico parcial Criterio senior en hitos concretos Construcción de cultura diaria Cualquier fase, necesidad puntual

El error más caro que vemos es contratar el perfil de estrategia para un problema de entrega. Entra alguien acostumbrado a pensar a dieciocho meses, se encuentra con un backlog atascado, y ninguna de las dos partes está contenta a los cuatro meses.

Conversación uno a uno entre responsable de ingeniería y desarrollador sobre prioridades del equipo

El coste real de acertar y de equivocarse

Hagamos las cuentas completas, no solo el salario.

Una búsqueda seria para este puesto rara vez baja de seis meses desde que se abre el proceso hasta que la persona firma. Súmale de dos a tres meses de rampa hasta que sus decisiones son mejores que las tuyas, porque necesita entender el negocio. Estás en ocho o nueve meses de horizonte. A eso añade el paquete: un fijo de cinco cifras altas según ciudad y perfil (pide referencias actualizadas de mercado antes de presupuestarlo, porque las cifras publicadas son poco fiables), más equity que en etapas tempranas suele expresarse en una fracción baja de un punto porcentual a un par de puntos, más el coste de oportunidad de las veinte o treinta horas que tú vas a dedicar a entrevistas.

Ahora el escenario malo. Si la incorporación no funciona y se rompe a los ocho meses, has perdido el dinero, has perdido el año, y además arrastras un equipo que ya se había reorganizado alrededor de esa persona. En nuestra experiencia, deshacer eso lleva otro trimestre. El equity, si estaba mal estructurado sin cliff, se queda fuera. Ese detalle ha hundido más cap tables de lo que se comenta en público.

¿Y el escenario bueno? También conviene cuantificarlo, porque es real. En los tres casos de nuestra cartera donde la incorporación era necesaria y salió bien, el efecto medible en los doce meses siguientes fue una reducción notable del tiempo de entrega y, sobre todo, la capacidad de contratar bien: cada uno de esos equipos incorporó entre cuatro y siete personas técnicas sin un solo fallo grave de selección. Eso, por sí solo, paga el salario.

La variable que casi nadie pone en la hoja de cálculo

Tu propio tiempo. Si eres fundador y estás dedicando más de la mitad de tu semana a decisiones técnicas que no te corresponden, el coste de no delegar ya está en tus números; simplemente no aparece en ninguna línea. Lo pagas en ventas que no cierras.

Cómo decidir en una tarde: seis preguntas y un umbral

Responde estas seis con un sí o un no. Sin matices, sin «depende». El matiz lo has leído ya en las secciones anteriores.

  1. ¿Tengo más de cinco personas técnicas en nómina o en contratación inmediata?
  2. ¿Nuestra ventaja competitiva está en el software que construimos?
  3. ¿Hay decisiones de arquitectura pendientes caras de revertir?
  4. ¿Voy a contratar tres o más perfiles técnicos en nueve meses?
  5. ¿Necesito a alguien que represente la tecnología ante inversores?
  6. ¿Dedico más del cuarenta por cien de mi semana a decidir cuestiones técnicas?

Cuatro o más síes: abre el proceso, y hazlo ya, porque tardarás medio año. Entre dos y tres: fórmula parcial durante seis meses y revisa la decisión al final; probablemente entonces tendrás cuatro síes y además sabrás mucho mejor qué perfil buscar. Cero o un sí: contrata ejecución, no mando. Un senior más y un lead con criterio te llevarán más lejos este año.

Nos hemos pasado varios años acompañando este salto, desde el primer prototipo hasta la estructura de equipo que sostiene un producto en producción, y es justo el recorrido que trabajamos en nuestro programa de MVP a SaaS. La conclusión, después de todas esas conversaciones, es poco espectacular: el error no es contratar mal, es contratar antes de saber qué problema estás resolviendo.

Lista de criterios escrita a mano para decidir si incorporar un responsable de tecnología en una startup

Preguntas frecuentes

¿Puede un desarrollador senior asumir el rol de CTO?

Puede, pero el ascenso automático al mejor programador del equipo es uno de los errores más repetidos. El puesto se evalúa en cuatro dimensiones: visión técnica, liderazgo, comunicación con interlocutores no técnicos y gestión de presupuesto. Solo una de las cuatro se demuestra escribiendo código. Si tu candidato interno domina las otras tres, adelante; si no, dale un arquitecto al lado y un plan de dos años.

¿Cuándo deja de ser necesario el puesto o tiene que evolucionar?

Cuando la estrategia tecnológica ya está estabilizada y el problema pasa a ser de organización y entrega, el rol se desdobla: entra un VP of Engineering y el responsable máximo se queda con arquitectura, producto y relación con inversores. Lo hemos visto alrededor de las quince o veinte personas técnicas. Si no se desdobla, se convierte en un cuello de botella con despacho.

¿Qué cambia si es cofundador con equity en lugar de contratado con salario?

Cambia casi todo. Un cofundador aporta compromiso a cinco años y coste de caja bajo, pero diluye y es dificilísimo de revertir si el encaje falla. Un contratado cuesta dinero hoy y se puede sustituir. Nuestra regla: equity significativo solo con cliff y vesting, y solo si esa persona iba a estar igual sin acciones.

Conclusión

Resumiendo lo que importa: por debajo de cinco personas técnicas y sin un producto cuyo diferencial viva en el código, lo que necesitas casi siempre es capacidad de ejecución. Por encima de ese umbral, o cuando la arquitectura es la estrategia, el liderazgo tecnológico deja de ser un lujo y se convierte en la pieza que evita decisiones caras de deshacer.

Y en medio, que es donde está la mayoría, existe una zona amplia y poco explorada: dedicación parcial, asesoría, interim. Más barata, reversible y sorprendentemente eficaz. Nadie la pone en el pitch deck, pero funciona.

Founder & Software Engineer
Ingeniero de Software y Desarrollador Full Stack con más de 10 años de experiencia operativa. Dirige MVPtoSaaS aplicando los mismos estándares de fiabilidad y rendimiento exigidos en sistemas industriales y de alta criticidad. El enfoque de Felipe asegura que cada producto que transita por MVPtoSaaS cuente con código limpio, bases de datos optimizadas para alta concurrencia y despliegues automatizados preparados para el crecimiento sostenido sin deuda técnica.