Founding engineer: lo que un founder no técnico tiene que saber antes de hacer esta contratación

Una founder con la que llevaba meses hablando me llamó un martes por la tarde. Acababa de firmar una oferta con el ingeniero que intentaba contratar desde el cierre de la semilla. Equity: 4%. Salario: $185K. Cargo: Founding Engineer. Quería que mirara la carta de oferta antes de enviarla.

La leí dos veces. La llamé de vuelta.

“¿Te das cuenta de que acabas de contratar a tu CTO?”, le dije.

“No, no. Es un founding engineer. Él construye el producto. El CTO lo contrato después.”

“Ya. Pero la persona a la que le acabas de dar 4% va a ser dueña de cada línea de código de tu empresa durante los próximos dieciocho meses. Va a elegir el stack. Va a elegir la base de datos. Va a decidir qué se refactoriza y qué se deja parchado. Si traes un CTO por encima de él en nueve meses, ¿qué crees que pasa?”

Silencio. Después: “Joder.”

No envió la oferta. Pasamos las dos horas siguientes reescribiendo el rol, el equity y la conversación que estaba por tener. El ingeniero terminó entrando. El título se mantuvo. La estructura debajo del título se arregló antes de endurecerse como un problema.

Esa llamada es la razón por la que este artículo existe.

¿Qué es un founding engineer?

Un founding engineer es el primer ingeniero que una startup contrata como empleado con equity, no como freelance ni como contratación fraccional, para ser dueño del build técnico del producto antes de que exista un CTO o un equipo de ingeniería.

Esa es la respuesta de manual. Cubre, más o menos, la mitad de lo que estás comprando de verdad.

La otra mitad es la parte que los blogs de reclutamiento omiten. Un founding engineer es la única persona en tu nómina que va a conocer el codebase entero. Va a estar solo en el build los primeros 12 a 24 meses. Va a absorber cada ambigüedad de producto que le pases, traducirla a sistemas, y vivir con las consecuencias cuando cambies de opinión. Va a fijar los defaults técnicos que los próximos diez ingenieros van a heredar. Y, como entró cuando la empresa todavía era riesgosa, va a tener una porción del cap table que, si la empresa funciona, lo hace rico de una manera que ningún ingeniero futuro va a serlo.

Esa es la contratación. No es un dev. No es un contratista. Ni siquiera es un IC senior de una empresa grande. Es una contratación a nivel de founder, con una porción de equity más pequeña y un alcance más estrecho, pero con el mismo peso estructural.

Si no entiendes eso, te vas a equivocar con la oferta, con el título, con el equity y con la relación. Antes de escribir la vacante, ten claro contigo mismo qué estás haciendo.

Founding engineer vs CTO: ¿a cuál de los dos estás contratando, en realidad?

Aquí es donde la mayoría de los founders no técnicos se tropieza, y es el error más fácil de corregir si lo detectas pronto.

Un CTO es un ejecutivo. Marca dirección técnica, gestiona ingenieros, va a la reunión del board, conduce la conversación de arquitectura con el resto del liderazgo y es dueño de la reputación técnica de la empresa en el mercado. El trade-off que trae es liderazgo a cambio de velocidad de IC. La mayoría de los CTOs en etapa temprana pasan menos de la mitad de la semana escribiendo código.

Un founding engineer es IC. Construye. Toma una idea de producto a medio hacer y entrega algo que un cliente que paga puede usar. Es el pulso técnico de la empresa, pero no gestiona equipo porque todavía no hay equipo.

La pregunta del CTO y la pregunta del founding engineer no son la misma contratación. La forma de distinguirlas es preguntarte, con honestidad: ¿necesito a alguien en la sala del board ahora, o necesito a alguien entregando código?

Si la respuesta es “en la sala del board”, buscas un CTO. El mercado de esa contratación es escaso, lento y caro. La mayoría de los founders no técnicos en etapa temprana no pueden, en realidad, contratar un CTO de verdad en ese momento, e intentarlo casi siempre produce un candidato sobrecualificado para el trabajo de IC y subcualificado para el rol ejecutivo.

Si la respuesta es “entregando código”, quieres un founding engineer. El mercado es más profundo, el salario es menor, y quien dice sí es alguien cuya comp va a estar fuertemente ponderada por equity, porque el atractivo del rol es la propiedad del canvas técnico.

Un patrón común que sale mal: contratar a un founding engineer con comp de founding engineer, darle un alcance de CTO (“vas a definir la dirección técnica, dirigir la ingeniería, ser dueño de la arquitectura para siempre”), y traer a un CTO de verdad por encima de él un año después. El founding engineer se vuelve un senior IC callado que se siente degradado, o se va con su equity y su contexto. Lo hemos visto pasar tres veces en los últimos dieciocho meses. En dos de ellas, el founding engineer se fue.

Empareja el título con la comp, la comp con el alcance, y el alcance con donde está, de verdad, tu build.

Founding engineer vs co-founder: la línea que importa

Hay una tercera línea que vive borrosa, y pesa más de lo que su nombre sugiere.

Un co-founder es dueño de la empresa. Firma documentos. Asume responsabilidad legal y financiera. Comparte el perfil de riesgo del founder: salario bajo o nulo en los primeros días, vesting de cuatro años desde el día uno de la existencia de la empresa, con derechos y protecciones que aparecen en el cap table desde el momento de la constitución.

Un founding engineer es empleado. Entra después de que la empresa existe. Su grant de equity se estructura como concesión del option pool, con vesting desde su fecha de inicio y precio de ejercicio fijado por una valuación 409A que ya refleja algo de valor de la empresa. Cobra un salario de verdad desde el primer día. Puede renunciar sin que sea un evento a nivel de founder.

Los founders a veces intentan partir la diferencia. “Es básicamente un co-founder, sólo que entrando tarde.” Tres meses después, el ingeniero sigue con un grant estándar de empleado, y el founder se pregunta por qué no está tan involucrado como esperaba.

Si quieres la relación de un co-founder, estructúrala como una relación de co-founder. Eso significa equity a nivel founder (más cerca de 10-25% que de 1-5%), vesting de founder, voz de founder en la empresa. También significa ceder una porción real de tu cap table.

Si no puedes hacer eso, lo que quieres es un founding engineer. Sé honesto al respecto. Págale bien, dale propiedad sobre el canvas técnico, y no le prometas lo que no puedes cumplir.

La versión honesta de esta conversación, hecha al principio, es la diferencia entre una contratación que dura cinco años y una contratación que termina en disputa de cap table.

¿Cuánto equity debería recibir un founding engineer?

El rango de mercado, al momento de escribir esto, está aproximadamente entre 0,5% y 2% para un founding engineer contratado en el año posterior a la semilla, con vesting de cuatro años y cliff de un año. Dentro de ese rango, el número se mueve con palancas específicas.

Palancas que empujan el equity hacia arriba:

• El candidato ya lo hizo antes. Fue founding engineer en una startup que envió producto, aunque la empresa no haya tenido exit. El pattern matching importa.
• El candidato está aceptando una bajada significativa de comp respecto a su último trabajo.
• El candidato está entrando antes del cierre de la semilla, cuando el riesgo es materialmente mayor.
• El candidato tiene una especialización técnica concreta que el producto necesita y que no puedes conseguir en otro sitio.

Palancas que empujan el equity hacia abajo:

• La empresa ya tiene un producto en el mercado, ingresos reales y validación. El descuento por riesgo se desvanece.
• El salario está en o cerca del mercado, así que el equity no compensa una bajada de comp.
• El candidato se incorpora después de la Serie A, con una 409A que ya se ha movido.

Dos cosas que evitar.

Primero, no des equity para ganar al candidato. Hemos visto a founders no técnicos subir la oferta de equity un 50% en la llamada de cierre para arrancar el sí. El candidato dijo que sí; el founder lo pagó en la siguiente ronda, cuando el cap table parecía desbalanceado y el diligence del inversor lo marcó. Si el candidato es la persona equivocada al 1%, va a seguir siéndolo al 1,5%. Encuentra otra palanca (fecha de inicio, salario, alcance, título) o encuentra otro candidato.

Segundo, no des equity sin vesting. Single-trigger acceleration en el grant de un founding engineer es un disparo en el pie. Cualquier vesting menor a cuatro años, también. El cliff pesa más que el porcentaje. Un cliff de dos años sobre un grant de 1% le da al founder un año de opcionalidad. Un grant sin cliff le da al ingeniero apalancamiento al día 90.

Cuando dudes, mira el reporte anual State of Equity de Carta y compara con empresas de tu etapa y tu geografía. Los números cambian cada año, y los benchmarks públicos son más precisos que lo que vas a escuchar en tu propia red.

Las tres trampas en las que cae el founder no técnico al contratar un founding engineer

Las hemos visto en tiempo real, con clientes a los que seguimos atendiendo y con founders que decidieron hacerlo solos.

Trampa uno: contratar a alguien bueno en la tecnología y malo en la ambigüedad.

Un ingeniero senior de una empresa de 400 personas es, muchas veces, peor founding engineer que un ingeniero semi-senior de una empresa de 12. La habilidad que el founding engineer necesita no es profundidad en un stack técnico. Es tolerancia a requisitos vagos, el criterio para tomar una decisión 70%-correcta rápidamente y enviarla, y el temperamento de hacer su propio razonamiento de producto cuando el founder todavía está descubriendo qué construir. Los ingenieros que crecieron en entornos bien especificados a menudo se bloquean ante una idea a medio hacer y la orden de hacerla real. El founder lee el bloqueo como “necesita más dirección” y empieza a escribir tickets, que es lo contrario del motivo por el que contrató al ingeniero.

Tamiza la tolerancia a la ambigüedad como tamizas la habilidad técnica. Pregunta: cuéntame un proyecto donde los requisitos no estaban claros y tuviste que averiguar qué construir. Si la respuesta es una narrativa pulida y sin fricción, te está contando el trabajo como quiere recordarlo. Si la respuesta es “nos equivocamos con el spec dos veces, luego me senté con el cliente durante dos horas y descubrimos qué importaba”, ese es el founding engineer.

Trampa dos: contratar a alguien que no puedes gestionar.

El founding engineer entra buscando autonomía. Quiere enviar sin que le indiquen cómo. Pero autonomía no es lo mismo que ausencia de relación. Un founder no técnico todavía tiene que poder preguntar “¿es esa la decisión correcta?” y recibir una respuesta real, en un lenguaje sobre el que pueda actuar. Si el ingeniero no puede explicar trade-offs técnicos como consecuencias de negocio, el founder va a asentir, aprobar y mirar cómo se toman decisiones que no puede evaluar. Es el comienzo del problema de la caja negra del que esta marca lleva años escribiendo.

El tamiz aquí es una conversación, no una prueba de código. Pasa una hora hablando sobre una decisión real que el candidato tuvo que tomar en su último trabajo. ¿Explicó el trade-off en términos que pudiste seguir? ¿Te empujó cuando le propusiste algo que no tenía sentido? ¿Te hizo sentir respetado, o pequeño? Si la conversación fue buena, la relación de trabajo probablemente también lo sea.

Trampa tres: contratar a alguien que no puede crecer hacia mánager, y descubrirlo en el mes nueve.

La mayoría de founding engineers va a tener, eventualmente, que contratar y gestionar a los siguientes dos o tres ingenieros. No todos quieren. Algunos founding engineers excelentes son profundamente IC y van a resentir en silencio cada hora obligada en un 1:1. Está bien. Pero tienes que saberlo el día uno.

Ten la conversación de forma explícita. “En doce a dieciocho meses, el equipo va a crecer. Algunos founding engineers crecen hacia el rol de engineering manager. Otros se quedan IC y contratamos un mánager por encima. ¿Cuál de las dos versiones se parece más a ti?” Si no tiene una respuesta clara, es porque no se conoce lo suficiente. Es una bandera.

El test de preparación de siete días

Antes de escribir la vacante, corre este test sobre ti mismo. Te va a decir si estás listo para hacer esta contratación, o si deberías esperar tres meses y seguir trabajando con un equipo externo un ciclo más.

Pasa los próximos siete días respondiendo, por escrito, las cinco preguntas siguientes. Si no puedes, no estás listo para contratar un founding engineer. La contratación va a fallar no porque el ingeniero esté mal, sino porque la empresa debajo de él no está lista.

1. ¿Qué tiene que hacer el producto, en lenguaje plano, dentro de seis meses? No el deck de visión. El producto enviado. Una página.
2. ¿Quiénes son los tres primeros clientes que lo usan, y por qué te están pagando? Si la respuesta es “lo descubrimos después del lanzamiento”, el founding engineer lo va a descubrir por ti. Va a tomar las decisiones de diseño con cliente quieras o no.
3. ¿Cuál es el presupuesto de ingeniería para los próximos 18 meses, incluyendo salario, equity, infraestructura y un colchón para la siguiente contratación? Si no puedes responder con precisión del 20%, vas a quedarte sin runway hacia el mes diez, y la conversación con el ingeniero sobre recortes de salario o layoffs va a ser la peor de tu año.
4. ¿Cómo es el mes 12 si la contratación funciona? Qué está enviado, cuál es el ingreso, cuál es el equipo. Si no puedes verlo, el ingeniero tampoco, y el grant de equity es sólo un número en el papel.
5. ¿Cómo es el mes 12 si no funciona? Cuál es la conversación de salida. Quién se queda con el código. Quién es dueño de los compromisos con cliente. La conversación más difícil en cualquier contratación de founding engineer es el desenlace. Los founders que la pueden nombrar al principio, normalmente no terminan teniéndola. Los que no, suelen terminarla teniendo.

Si puedes responder las cinco con claridad, contrata. Si no, la brecha está en la empresa, no en el candidato. Arregla la brecha primero.

Cuándo no contratar un founding engineer (y qué hacer en su lugar)

Hay tres situaciones en las que la decisión correcta es esperar.

No has validado el producto. Pre-validación, lo que necesitas es throughput en experimentos, no propiedad de codebase. Un equipo externo capaz o un contratista senior va a moverse más rápido que un founding engineer, porque no necesita ser embarcado en una visión que sigue cambiando cada semana. Contrata al founding engineer cuando tengas algo que valga la pena defender.

No puedes articular qué quieres del rol. Si te encuentras escribiendo la vacante y copiando texto de la vacante de otra empresa, frena. El costo de equivocar esta contratación es lo bastante alto como para que los specs nebulosos sean un riesgo activo. Un CTO fraccional por tres meses puede ayudarte a escribir el spec, definir la vara técnica y filtrar candidatos. Es una forma mucho más barata de descubrir que, en realidad, todavía no necesitas esta contratación.

Estás contratando por miedo, no por estrategia. Hay un patrón emocional concreto que empuja al founder no técnico a contratar un founding engineer antes de tiempo: un consejero le dijo que debería tener su propio equipo técnico, un par acaba de contratar uno, el equipo externo no es perfecto y el founder está perdiendo confianza. Las contrataciones por miedo fallan más que las contrataciones por estrategia. La solución suele ser una conversación, no una vacante. Habla con dos o tres operadores que contrataron a su founding engineer en el momento correcto, y pregúntales qué harían diferente. La respuesta rara vez es “debería haberlo contratado antes”.

Si ninguna de esas tres se aplica, y puedes responder las cinco preguntas con claridad, escribe la vacante. Usa el rango de equity de arriba. Evita las tres trampas. Y pasa más tiempo en la conversación que en la prueba técnica, porque es en la conversación donde la contratación vive o muere.

FAQ

¿Cuál es la diferencia entre un founding engineer y la primera contratación de dev?
Un founding engineer se contrata a tiempo completo, con equity, para ser dueño del build técnico del producto. La primera contratación de dev suele ser una relación transaccional: un contratista o un empleado junior traído para ejecutar un alcance definido. El founding engineer firma con la empresa; el primer dev firma con el proyecto.

¿Un founding engineer puede convertirse en CTO después?
A veces, pero no por defecto. Las habilidades se solapan menos de lo que los títulos sugieren. Un gran founding engineer es un gran IC; un gran CTO es un gran ejecutivo. Algunas personas crecen hacia las dos cosas. Muchas no. Si quieres que el founding engineer termine siendo el CTO, nómbralo explícitamente en la conversación de oferta, y construye desarrollo real de habilidades de gestión entre los meses 9 y 18. No esperes a que ocurra solo.

¿Cuánto tarda contratar a un founding engineer?
Planea dos a seis meses. Los buenos no están en el mercado. Están en conversaciones a través de presentaciones cálidas, referencias y redes pequeñas. El inbound frío rara vez produce la contratación correcta. Reserva el tiempo, trabaja la red, y no comprimas el calendario para compensar un compromiso del board.

¿Cuál es el título correcto: founding engineer, founding software engineer o algo más?
Para el trabajo, no importa. Para el candidato, sí. “Founding engineer” lleva más expectativa de equity que “senior engineer” o “lead engineer”, y los candidatos lo van a tarifar así. Elige el título que case con la comp y con el alcance, y no infles el título para ganar al candidato sin inflar el resto del paquete a la par.

¿Debería contratar un founding engineer o trabajar con un partner de software en su lugar?
Depende de dónde estés. Un partner de software se mueve más rápido pre-validación, y te da opcionalidad si la idea de producto cambia. Un founding engineer compone. Se vuelve más rápido cada mes, y en el hito de 18 meses conoce tu negocio mejor de lo que ningún equipo externo va a hacerlo. La mayoría de los founders no técnicos con los que trabajamos hacen las dos cosas en momentos distintos de la empresa. La versión honesta: el founding engineer es la contratación correcta cuando tienes algo sobre lo que estás seguro de querer componer. Antes de eso, estás pagando caro por componer sobre la base equivocada.