El CTO que no puedes contratar — y por qué todavía no es tu problema

La mayoría de los fundadores no técnicos intenta contratar un CTO en el momento equivocado. Hasta la Serie A, la decisión correcta casi siempre es un partner de delivery. Cómo saber en qué punto estás.

Un fundador con el que trabajamos el año pasado nos contó, tomando un café en São Paulo, que llevaba cuatro meses buscando un CTO. Habló con veintitrés personas. Ninguna aceptó. Dos dijeron que sí y luego desaparecieron antes de firmar. Terminó el café y nos hizo una pregunta que, en ese punto de su ronda, era una emergencia: “¿A quién contratan los fundadores no técnicos cuando no consiguen el CTO?”

Esa es la pregunta equivocada. La correcta es: ¿deberías estar contratando uno?

La mayoría de los fundadores en etapa temprana que conocemos están convencidos de que sí. Leyeron el playbook. El playbook dice: contrata al cofounder técnico, dale 20–30% de la empresa, lanza el producto, levanta la ronda. El playbook tiene cuarenta años en tiempo de startup. Se escribió cuando no había otra forma de construir software. Hoy la hay.

Hasta la Serie A — y muchas veces más allá — la decisión correcta para un fundador no técnico casi nunca es contratar un CTO. La decisión correcta es trabajar con un partner de delivery que se comporte como uno. La diferencia es sutil, el costo es dramático, y la mayoría de los fundadores no la nota hasta que ya entregó el equity.

Lo que un CTO realmente hace (y por qué no necesitas la mayor parte)

Antes de discutir si contratar, vale ser específicos sobre lo que estamos contratando. Un CTO real, en una empresa con capital de riesgo, hace cinco trabajos. Define la arquitectura del producto. Contrata y gestiona al equipo de ingeniería. Es dueño del roadmap técnico y de los trade-offs frente al roadmap de negocio. Representa a ingeniería ante el board, los inversores y los clientes enterprise. Y — usualmente quinto en la lista, a pesar de lo que los fundadores asumen — a veces escribe código.

Para una empresa pre-seed o seed, los trabajos tres, cuatro y cinco son casi totalmente ficticios. No hay equipo de ingeniería que gestionar. Al board todavía no le importa. Los clientes enterprise no existen. Lo que de hecho necesitas, en los primeros dieciocho meses, es el primer trabajo — alguien que arquitecte el sistema — y un equipo pequeño que ejecute esa arquitectura sin convertir al fundador en cuello de botella.

Un partner de delivery hace la parte del arquitecto y aporta el equipo. Una contratación de CTO hace la parte del arquitecto y tú aportas el equipo. En un modelo, el problema de recursos se resuelve el día uno. En el otro, se vuelve el primer proyecto del CTO — y suele consumir seis meses y la mayor parte del runway que levantaste con la ronda.

La cuenta que los fundadores no hacen

Aquí va la comparación que nadie hace con los fundadores, porque la gente en la sala suele tener interés en uno de los dos lados.

Contratar un CTO en seed: entregas entre 15% y 25% del equity y pagas un salario que en EE. UU. va de US$ 200–280k/año, en Brasil de R$ 30–60k/mes, y en hubs hispanos como CDMX o Madrid suele estar en torno a US$ 8–15k/mes. Entra y dedica los dos primeros meses a reclutar. Hace dos primeras contrataciones. A los tres meses tienes tres ingenieros, ningún producto en mano, y el costo fijo más alto del P&L es ingeniería. Pasarás los próximos doce meses gestionando al gerente que gestiona al equipo. El CEO que dijo “no quiero ser tech manager” será, de hecho, tech manager.

Trabajar con un partner de delivery: pagas un fee de proyecto — para una primera versión típica, entre US$ 80k–200k repartidos en cuatro a nueve meses. El equipo está armado el día uno. La conversación de arquitectura ocurre con una persona senior antes de la primera línea de código. Lanzas, vendes al primer cliente, iteras — sin quemar runway en personas que aún no puedes gestionar productivamente.

A los dieciocho meses, cuando la empresa es más grande y el costo de desarrollo vía partner por feature empieza a superar al de un equipo interno, ahí es cuando contratas. Para entonces ya sabes exactamente qué tipo de CTO necesitas, porque el código lo dice. Contratas a alguien que encaje con la arquitectura que ya tienes, en lugar de adivinar la arquitectura que vas a necesitar antes de que exista cualquier código.

“Pero yo quiero un cofounder”

Aquí es donde los fundadores empujan de vuelta. No quieren tercerizar el producto. Quieren un socio. Quieren a alguien que no duerma pensando en el mismo problema. Quieren un nombre en el deck.

Lo entendemos. Es una preferencia real, y no es errónea. Pero vale ser honestos sobre el costo y lo que de verdad recibes.

Un cofounder técnico que entra en seed rara vez es la persona que construye la empresa que tendrás en la Serie A. Las habilidades que la empresa necesita en el mes dos — escribir código, lanzar rápido, montar la base de datos — no son las que necesita en el mes veinte — contratar ingenieros, fijar la cultura de ingeniería, particionar el sistema, lidiar con auditorías de seguridad. La cantidad de CTOs que hace ambas cosas bien, en sucesión, en un equipo de menos de cincuenta personas, es pequeña. La cantidad que cree que puede hacerlo es grande.

Si quieres un cofounder, busca uno para la parte del negocio donde tienes un gap permanente. Un cofounder go-to-market si eres especialista de dominio. Un cofounder de producto si eres comercial. Un segundo cofounder comercial si eres builder. El trabajo técnico — hasta que tengas suficiente como para mantener un equipo a tiempo completo, en algo que entiendes lo bastante como para dirigirlo — puede liderarlo un partner sin perder nada importante. La excepción es cuando el trabajo técnico es el moat defensivo del producto (un producto pesado en investigación de IA, infraestructura profunda, hardware-software combinado), e incluso ahí la mayoría de los fundadores sobreestima cuánto del código inicial es el moat.

Cómo saber de qué lado estás

Dos preguntas. Respóndelas honestamente, por escrito, antes de tomar la próxima reunión con un candidato a CTO.

Primera: ¿podría, ahora mismo, escribir un brief de una página sobre lo que queremos construir en los próximos seis meses — qué hace, quién lo usa, cómo se ve el éxito, con qué tiene que integrarse? Si la respuesta es sí, no necesitas un CTO; necesitas un partner de delivery que tome ese brief y lo ejecute. Si la respuesta es no, el gap está aguas arriba de ingeniería — es claridad de producto. Un CTO no resolverá eso por ti más rápido que otro mes de conversaciones con clientes.

Segunda: si un ingeniero senior entrara mañana, ¿qué le asignaría en su primer mes? Si la respuesta honesta es “que descubra qué construir” — eso es un gap de producto, no de ingeniería. Si la respuesta es “construir las features X e Y, aquí están las specs” — no necesitas una contratación, necesitas ejecución. Si la respuesta es “gestionar a los cuatro ingenieros que acabamos de captar dinero para contratar” — te has convencido del problema equivocado.

La única respuesta honesta que justifica una contratación de CTO en seed es: tenemos una decisión técnica compleja que se compone a lo largo de años, la defensibilidad del producto vive en esa decisión, y no puedo, con buena conciencia, tercerizarla. Es una situación real. También es rara. La mayoría de los fundadores no está en ella; cree que sí porque el playbook le dijo que debería estarlo.

Qué significa de verdad “partner de delivery”

Usamos la expresión con cuidado, porque las agencias la han abusado tanto que casi no significa nada. Un partner de delivery — del tipo que describimos — se parece más a un CTO fraccional que a una agencia de desarrollo. La relación tiene cuatro propiedades.

El ingeniero senior que define el alcance del proyecto es el mismo que revisa el código seis meses después. No hay handoff de comercial a delivery, porque quien prometió la arquitectura es quien la construye. Ves cómo se toman las decisiones — cada decisión de arquitectura es una conversación real, no un entregable. Los trade-offs son visibles. El equipo escribe código que podrás darle a otra persona para mantener cuando finalmente contrates internamente — porque la transición es un objetivo explícito del engagement, no una idea de último minuto.

Esa última propiedad es la que la mayoría de los fundadores no ve al evaluar partners. El partner equivocado construye un sistema que solo él puede mantener, porque eso te ata. El partner correcto construye algo que un futuro CTO podrá levantar limpio — así sabes que el partner tiene skin en tu juego de largo plazo, no solo en la factura del trimestre.

Cuándo, en serio, contratar

Hay señales. La más clara es volumen — cuando hay trabajo de ingeniería, semana tras semana, suficiente para que pagarlo a través del partner sea más caro que correr un equipo in-house, y ese volumen ha sido estable durante al menos seis meses. Suele ocurrir entre Serie A y Serie B en SaaS B2B, y antes en productos de consumo capital-light.

La segunda señal es velocidad de decisión técnica — cuando la frecuencia de decisiones que tienes que tomar es lo bastante alta como para que la comunicación con el partner se vuelva un impuesto. En ese punto, un líder interno es más rápido, aunque no sea estrictamente mejor.

La tercera señal es gravedad de talento — cuando los ingenieros que quieres reclutar solo vendrán si tienes un CTO técnicamente creíble al que quieran reportar. Esta señal llega más tarde de lo que los fundadores imaginan; los ingenieros senior aceptan unirse a una empresa en crecimiento con un partner de delivery fuerte si el fundador es honesto sobre el modelo y hay un camino claro hacia la primera contratación de VP/CTO.

Cuando contrates, contrata a alguien que encaje con el código que el partner construyó, no con la idea abstracta de “un CTO”. El trabajo del partner es hacer esa contratación más fácil, no más difícil. Esa es la prueba.

Lo que nadie dice en voz alta

Hemos visto a docenas de fundadores en seed atravesar esta decisión. Los que contrataron temprano casi todos dijeron, doce meses después, que ojalá no lo hubieran hecho. Los que primero eligieron un partner casi nunca dijeron lo contrario. La asimetría no es sutil.

Hay una razón. La presión para contratar un CTO en seed es, en su mayor parte, social. Viene de inversores que prefieren un equipo “completo” en el deck. Viene de pares que tomaron la misma decisión antes de que las partnerships de software a medida fueran creíbles. Viene de la propia ansiedad del fundador de ser la única persona del cap table que no escribe código. Ninguno de esos es un argumento sobre lo que conviene a la empresa. Son argumentos sobre lo que es cómodo para el fundador.

La respuesta incómoda es que, en los primeros dieciocho meses, la mayoría de los fundadores no técnicos no necesita un CTO. Necesita a una persona senior que ya haya hecho este tipo de cosa antes, un equipo pequeño que ejecute, y la disciplina de mantener su propio rol apuntando a clientes, distribución y negocio — no al organigrama de ingeniería que aún no existe.

Cuando llegue ese día, contrata. Hasta entonces, construye.