TL;DR
La due diligence técnica de un CTO que recomendamos en IT Workers consta de 5 sesiones de 90 a 120 minutos: visión técnica, code review con asesor externo, liderazgo y org design, stakeholder management con board, e incidentes y postmortems. Para un founder no técnico, la metodología sustituye al criterio técnico personal por un proceso estructurado que reduce el riesgo de bad hire en un cargo donde el error cuesta 18 a 24 meses de productividad del área de ingeniería.
Hace 18 meses, el CEO de una fintech B2B en Santiago contrató a un CTO con currículum impecable: 12 años de experiencia, ex-empresa global con buena reputación, charla en una conferencia conocida, perfil de LinkedIn pulido. El proceso de evaluación duró dos semanas. Tres entrevistas, una llamada con un inversor y dos referencias telefónicas. Catorce meses después, el CTO renunció dejando al equipo de 22 ingenieros con tres microservicios sin documentar, una migración a Kubernetes a medio camino, un Staff Engineer renunciando con dos managers más en proceso, y un costo de cloud que se había duplicado sin que nadie supiera bien por qué. El CEO me llamó. La primera frase fue: "¿Cómo lo evalúo bien esta vez?".
Este artículo responde exactamente esa pregunta. No es un listado genérico de preguntas para hacer en entrevista. Es un framework operacional de cinco sesiones, diseñado en IT Workers tras más de 100 búsquedas C-level tech gestionadas, que permite a un founder no técnico evaluar a un candidato a CTO con el mismo rigor que tendría si él mismo fuera ingeniero senior. La premisa central es simple: el founder no técnico no compite con el conocimiento técnico del candidato, sino con un proceso estructurado que reduce su propia incertidumbre.
Lo que viene a continuación cubre por qué los founders no técnicos fallan al contratar CTO, las cinco sesiones del framework con su objetivo, agenda y red flags, la matriz completa de banderas rojas por sesión, cómo estructurar las referencias 360 grados con cinco fuentes, los errores típicos que se repiten en cada proceso, el dilema CTO interim versus full-time, un FAQ extendido con 10 preguntas y un cierre con CTA. Total estimado: tres mil doscientas palabras escritas con la única regla de ser útil para alguien que firma una oferta sin saber programar.
1. Por qué los founders no técnicos fallan al contratar un CTO
Antes del framework, conviene entender el patrón. Tras más de 100 búsquedas C-level tech, los procesos que terminan mal comparten cinco causas recurrentes. Ninguna es por falta de inteligencia del founder. Son sesgos estructurales de evaluar algo que no se domina.
Causa 1: Confundir presencia con sustancia
El candidato habla bien, usa palabras correctas (microservicios, escalabilidad, observabilidad, MLOps), tiene buena energía en la sala y proyecta confianza. El founder no técnico interpreta esa confianza como dominio técnico. Pero la confianza es performance, y muchos candidatos a CTO han hecho carrera entera vendiendo presencia sin acompañarla de profundidad real. La única forma de detectarlo es bajar al detalle de decisiones específicas que el candidato tomó, qué descartó y qué aprendería hoy. Si la respuesta es vaga o defensiva, hay una señal.
Causa 2: Confiar en marcas previas
Trabajar en una empresa global reconocida no implica haber sido un buen ingeniero ni un buen líder. Implica que pasó el filtro de contratación de esa empresa. Los founders no técnicos suelen contratar por el logo del CV, asumiendo que la empresa anterior hizo la due diligence por ellos. Es un atajo barato. Hay malos CTOs con currículum brillante y excelentes CTOs con currículum poco ortodoxo. Lo que importa es qué hicieron, qué decidieron y qué dejaron en cada paso, no en qué empresa lo hicieron.
Causa 3: Subestimar el costo de un mal hire
Una mala contratación de Senior Engineer cuesta entre 6 y 9 meses de salario. Una mala contratación de CTO cuesta entre 18 y 24 meses de productividad del área completa de ingeniería. El founder no técnico calcula el costo solo como el salario del CTO, sin contar la rotación que genera, las decisiones de arquitectura que cuesta entre 6 y 18 meses revertir, ni la pérdida de confianza del board. Subestimar el costo real lleva a procesos apresurados.
Causa 4: Falta de panel técnico externo
El founder no técnico entrevista solo o acompañado de su CFO o COO, ninguno de los cuales puede validar la profundidad técnica del candidato. La solución no es transformar al founder en ingeniero. Es contratar a un asesor técnico externo (un Staff Engineer o un VP Engineering de la red del founder) que se siente 90 minutos con el candidato a evaluar arquitectura y código. Sin ese panel, el founder está adivinando.
Causa 5: Cerrar el proceso bajo presión
Casi todos los procesos malos comparten un patrón final: "el candidato tiene otra oferta, hay que decidir esta semana". Esa frase activa el sesgo de escasez y acorta la due diligence. Pero un CTO que firma bajo presión rara vez es el correcto. Un buen candidato a CTO entiende que la decisión es mutua y respeta un proceso de tres a cinco semanas. Si presiona artificialmente, ya es un dato de cómo va a operar con el board después.
2. El framework de 5 sesiones para evaluar a un CTO
El framework está diseñado para ejecutarse en tres a cinco semanas, con sesiones espaciadas de cuatro a siete días, lo que permite procesar lo conversado y validar contra referencias en paralelo. Cada sesión tiene un objetivo específico, una agenda concreta y un set de señales que el founder debe registrar. El orden de las sesiones no es casual: van de lo más estratégico (visión) a lo más operacional (incidentes), filtrando candidatos en cada paso.
Tasa de éxito de hiring CTO a 18 meses según método de evaluación (100 búsquedas C-level tech, IT Workers 2024-2026)
El gráfico anterior resume el dato base que justifica un framework estructurado: founders no técnicos que entrevistan sin método cierran procesos con un 38% de éxito a 18 meses; con un panel técnico externo suben a 56%; aplicando el framework completo de 5 sesiones con referencias 360 grados llegan al 81%. La diferencia entre adivinar y operar con método es alrededor de 43 puntos porcentuales de probabilidad de éxito.
Visión técnica y mapa de decisiones de los últimos 24 meses
Objetivo: entender cómo piensa el candidato. No qué sabe, sino cómo decide. Se pide al candidato que dibuje en un papel (literalmente, con plumón) la arquitectura del último sistema que lideró, identificando tres decisiones críticas que tomó y por qué. El founder no juzga el dibujo: observa si el candidato puede explicar trade-offs en lenguaje de negocio, si reconoce errores pasados y si tiene opiniones fundamentadas sobre alternativas.
Preguntas guía
Cuéntame de la última decisión técnica grande que tomaste. Qué descartaste y por qué. Qué harías distinto hoy con la información que tienes. Cómo medías si la decisión estaba funcionando. Quién en tu equipo se oponía y cómo cerraron el debate.
Señales positivas
Reconoce abiertamente decisiones que no funcionaron. Habla de trade-offs y no de soluciones absolutas. Atribuye éxitos al equipo y errores a sí mismo. Hace preguntas de negocio antes de proponer técnica. Explica en lenguaje claro sin condescendencia.
Code review en vivo y profundidad de arquitectura
Objetivo: validar la profundidad técnica real del candidato. Aquí el founder no opina: contrata a un asesor técnico externo (Staff Engineer, VP Engineering o CTO senior de la red) que conduzca la sesión. La estructura clásica es 30 minutos de revisar un repositorio o snippet propio del candidato, 30 minutos de discutir una decisión de arquitectura compleja (build vs buy, monorepo vs polyrepo, microservicios vs monolito) y 30 minutos de pair programming sobre un problema medio. El founder asiste como observador silencioso para evaluar cómo el candidato baja a lenguaje no técnico cuando se le pide.
Preguntas guía del asesor
Muéstrame código tuyo que estés orgulloso. Por qué este diseño y no aquel. Cómo medías la calidad del código en tu equipo. Cómo manejaste deuda técnica heredada. Qué métricas DORA monitoreabas.
Señales negativas
Defensividad cuando se cuestiona una elección. Incapacidad de explicar conceptos técnicos en términos simples cuando se le pide. Falta de opinión sobre trade-offs concretos. Atribuir todo el código bueno al equipo sin reconocer la propia contribución.
Liderazgo, org design y referencias entrantes
Objetivo: entender cómo construye y gestiona equipos el candidato. Esta sesión combina conversación con el candidato y, idealmente, una conversación de 30 minutos con uno de sus reportes directos en su empresa actual o más reciente, gestionada por el headhunter. El foco está en: cómo organiza su equipo (squads, chapters, guilds, modelos híbridos), cómo decide cuándo contratar versus desarrollar, cómo gestiona conflicto entre managers, cómo da feedback difícil y cómo despide cuando hay que despedir. El founder no técnico evalúa estas dimensiones mejor que cualquier asesor técnico, porque son de gestión humana.
Preguntas guía
Cuéntame del último ingeniero que despediste y cómo lo hiciste. Cómo decides cuándo promover a un manager. Cómo manejas a un Staff Engineer que tiene razón técnica pero no respeta procesos. Cómo balanceas roadmap con deuda técnica. Cómo era tu reunión 1 a 1 con tu segundo al mando.
Señales positivas
Habla de su equipo con respeto incluso al describir despidos. Tiene un modelo claro de cómo organiza ingeniería. Reconoce que el management es un skill aparte y no automático. Da ejemplos específicos con nombres y números, no generalidades.
Stakeholder management con board e inversionistas
Objetivo: probar cómo se comunica el candidato con audiencias no técnicas de alta exigencia. Idealmente se incluye a un board member o lead investor en la sesión, con un escenario hipotético: el candidato debe presentar el estado de la plataforma técnica, métricas relevantes y el plan a 12 meses, en 30 minutos, sin slides preparadas. Después se le hacen preguntas duras: por qué este costo de cloud, por qué este atraso, por qué este incidente. El founder evalúa: claridad ejecutiva, manejo de presión, capacidad de traducir lo técnico al lenguaje del board, y honestidad cuando no sabe algo.
Preguntas guía
Cómo le explicarías a un inversor por qué necesitas duplicar el equipo de ingeniería. Qué métricas reportarías mensualmente al board. Cómo manejas cuando el board te pide algo que técnicamente es mala idea. Cuéntame de una vez que tuviste que decirle no al CEO.
Señales negativas
Usa jerga técnica sin traducir. Evita números concretos. Acepta todo lo que pregunta el board sin disentir. No tiene métricas claras de qué reportaría. Tiembla cuando se le presiona o se pone defensivo en lugar de argumentativo.
Casos de incidentes y postmortems reales
Objetivo: probar la madurez operacional del candidato bajo presión. Aquí se pide al candidato que cuente con detalle un incidente de producción que vivió en los últimos 24 meses: qué pasó, cómo se enteró, qué hizo en los primeros 30 minutos, cómo coordinó al equipo, cómo comunicó al resto de la compañía, qué postmortem se hizo, qué cambió a raíz de eso. La sesión revela tres cosas que ninguna otra detecta: si el candidato tiene cultura de postmortem real, si distribuye accountability con su equipo y si reconoce el rol de su propio liderazgo en el incidente.
Preguntas guía
Cuéntame del peor incidente de los últimos 24 meses. Quién te avisó. Qué hiciste en los primeros 30 minutos. Quién lideró la respuesta. Cuándo y cómo le contaste al CEO. Qué cambió estructuralmente después. Quién pagó la cuenta interna.
Señales positivas
Tiene cultura de postmortem documentado. Distingue causa raíz de causa próxima. No personaliza el error (no busca culpables, busca sistema). Reconoce que aprendió. Identifica cambios concretos que hizo después.
¿Estás iniciando una búsqueda de CTO?
IT Workers entrega shortlist calificado de candidatos C-level tech en 7 a 14 días hábiles. Garantía 90 días. Coordinemos una conversación esta semana.
3. Matriz completa de red flags por sesión
Cada sesión del framework revela un tipo distinto de señal. La tabla siguiente compila las banderas rojas que aparecen recurrentemente en los procesos donde, en retrospectiva, el candidato terminó siendo un mal hire. No es un checklist exhaustivo, pero cubre el 80% de los casos donde el founder no técnico mira hacia atrás y dice "esa señal la vi y la ignoré".
| Sesión | Red flag | Por qué importa |
|---|---|---|
| Sesión 1 (Visión) | No reconoce ningún error técnico de los últimos 24 meses | Indica falta de aprendizaje activo o narrativa heroica. Un CTO con tres años sin equivocarse no existe. |
| Sesión 1 (Visión) | Habla en absolutos: "esto siempre es mejor que aquello" | Falta de pensamiento contextual. En ingeniería casi todo es trade-off. |
| Sesión 2 (Code review) | No puede mostrar código propio reciente | Un CTO de scale-up debe haber tocado código en los últimos 12 meses, aunque sea poco. |
| Sesión 2 (Code review) | Defensividad ante feedback técnico del asesor externo | Si no recibe feedback en una entrevista, mucho menos lo recibirá de su equipo. |
| Sesión 3 (Liderazgo) | Cuenta despidos sin empatía o como anécdota heroica | Despedir bien es uno de los actos más difíciles de un líder. La forma de contarlo revela carácter. |
| Sesión 3 (Liderazgo) | No tiene modelo claro de org design ni de promoción | Improvisar org design en una scale-up genera rotación cara y silenciosa. |
| Sesión 4 (Board) | Usa jerga técnica sin traducir o ignora preguntas de negocio | Un CTO que no se comunica con board destruye confianza en seis meses. |
| Sesión 4 (Board) | Acepta todo lo que dice el board sin disentir | Un CTO que no levanta la voz cuando ve mala idea es un CTO decorativo. |
| Sesión 5 (Incidentes) | Ningún postmortem documentado en los últimos 24 meses | Falta de cultura operacional. En producción los incidentes son inevitables; los aprendizajes no. |
| Sesión 5 (Incidentes) | Personaliza el error en una persona específica de su equipo | Buscar culpables en lugar de sistemas indica que su equipo no se siente seguro en él. |
| Transversal | No hace preguntas de negocio durante el proceso | Un CTO que no se interesa por el modelo de la empresa no va a alinear ingeniería con producto. |
| Transversal | Presiona artificialmente la decisión con otra oferta | El estilo de negociación durante el proceso replica el estilo de operar con el board después. |
Distribución de red flags detectadas por sesión (procesos C-level tech IT Workers 2024-2026)
El gráfico muestra que las sesiones 2 (code review) y 5 (incidentes) son las que más banderas rojas revelan en términos absolutos, mientras que la sesión 1 (visión) actúa como filtro inicial. Saltarse las sesiones 4 y 5 es uno de los errores más caros: el founder no técnico tiende a quedarse con la sesión 1 y la 3, porque son las más cómodas para él. Justamente por eso son insuficientes.
La pregunta no es si el candidato a CTO sabe construir software. Es si te puede explicar en cinco minutos por qué eligió esa arquitectura, qué descartó y qué haría distinto hoy. Si no logra esa traducción al lenguaje del founder, la sesión termina ahí.
Pablo Herrera, IT Workers
4. Cómo estructurar las referencias 360 grados con 5 fuentes
Las cinco sesiones del framework son lo que el candidato te muestra de sí mismo. Las referencias 360 grados son lo que el mercado dice del candidato cuando él no escucha. Ambas son necesarias. Un CTO con buenas sesiones y malas referencias es alguien que entrevista bien y opera distinto. La regla mínima razonable son cinco fuentes diversas. Menos de eso, el retrato es incompleto.
CEO o founder anterior
El jefe directo. Pregunta clave: contratarías de nuevo. Cuál era su principal punto débil. Cómo manejaba el conflicto contigo.
Par del C-level (CFO, COO o CPO)
Cómo trabajaba contigo cuando había desacuerdo. Cómo era en discusiones de presupuesto. Reportaba bien al board.
Reporte directo manager
Tenía 1 a 1 estructurados. Daba feedback útil. Te promovió o ayudó a crecer. Cómo manejaba a tu equipo.
Reporte directo IC senior
Defendía decisiones técnicas con argumentos. Te dejaba liderar. Aprendiste técnicamente con él. Lo recomendarías a un amigo.
Stakeholder no técnico (Product, Ventas o Marketing)
Se comunicaba claro. Cumplía compromisos. Defendía a su equipo o se escondía detrás. Hacía que ingeniería fuera socio o cliente.
Reglas operacionales para las referencias
No usar solo las referencias que el candidato propone: él propone gente que va a hablar bien. Pedir al headhunter o a tu red que consigan dos referencias adicionales que el candidato no listó (backchannel references). En la conversación, ir más allá de "qué tal era trabajando con él": pedir ejemplos específicos, momentos de conflicto, decisiones difíciles. Si el referente da respuestas evasivas o muy pulidas, ya es señal. Las referencias buenas vienen con anécdotas; las malas vienen con eufemismos.
5. Errores típicos del founder no técnico durante la due diligence
Más allá del framework, hay errores de comportamiento del founder que sabotean el proceso aunque la metodología sea correcta. Estos cinco se repiten en casi todos los procesos que terminan mal.
Error 1: Hablar más que escuchar
El founder, por entusiasmo o nerviosismo, termina hablando 60% de la sesión vendiendo la empresa. El candidato sale informado pero no evaluado. Regla práctica: el candidato debe hablar 70% del tiempo. Si después de una sesión de 90 minutos el founder no tiene tres páginas de notas, la sesión se perdió.
Error 2: No tomar notas en tiempo real
Confiar en la memoria a tres semanas vista es ilusorio. Cada sesión debe quedar documentada en un Notion, Google Doc o cuaderno físico con tres apartados: lo que dijo, lo que no dijo (preguntas evadidas) y lo que sentiste. La tercera columna es la más útil al revisitar después.
Error 3: Confundir química con fit
Sentirse cómodo con alguien en una sala no implica que va a operar bien contigo durante 3 a 5 años. La química es necesaria pero no suficiente. Hay CTOs encantadores que destruyen empresas y CTOs introvertidos que son fundadores silenciosos de éxitos. Filtrar por química es un sesgo, no un criterio.
Error 4: Hacer el proceso solo
Sin asesor técnico externo y sin board involucrado, el founder no técnico está jugando en desventaja informacional. Un panel mínimo es: founder + asesor técnico externo (sesiones 1 y 2) + un board member o lead investor (sesión 4). Si la empresa tiene CFO o COO senior, sumarlos a la sesión 3 también ayuda.
Error 5: No bloquear tiempo para reflexión
Después de la última sesión, dejar pasar mínimo 3 a 5 días antes de decidir. La euforia post-entrevista es real y engañosa. Revisar las notas en frío, releer las referencias, conversar con dos personas de confianza fuera del proceso. Las decisiones de C-level no se toman caliente.
6. CTO interim versus CTO full-time: cuándo cada uno
En algunos escenarios, la respuesta correcta no es contratar al CTO definitivo sino primero un CTO interim que estabilice y ayude a definir el rol real. La decisión no es entre dos tipos de profesionales: es entre dos momentos del proyecto.
Cuándo conviene un CTO interim
Cuando la empresa todavía no tiene claridad sobre qué CTO necesita (más operacional, más estratégico, más builder, más manager). Cuando el equipo de ingeniería lleva más de seis semanas sin liderazgo. Cuando hubo un incidente reciente que requiere alguien con experiencia para estabilizar antes de pensar en la búsqueda definitiva. Cuando la ronda de inversión está a tres a seis meses y necesitas que alguien represente tech ante due diligence de inversionistas sin que sea el CTO permanente.
Cuándo va directo al full-time
Cuando ya tienes claridad estratégica del rol, presupuesto cerrado, el equipo de ingeniería es funcional y solo falta el liderazgo definitivo. Cuando el equity asignado es competitivo y atrae candidatos full-time de calidad. Cuando el founder tiene tiempo y energía para un proceso de tres a cinco semanas sin atajos. En estos casos, contratar interim primero solo retrasa la decisión final.
Costos comparativos
Un CTO interim factura típicamente entre 12 y 20 millones de pesos al mes en Chile para scale-ups (3 a 9 meses de duración promedio). Un CTO full-time tiene salario equivalente más equity. El interim sale más caro por mes pero evita una contratación apresurada que cuesta 24 a 40 millones directos más el costo indirecto de la rotación. La decisión es de gestión de riesgo, no solo de presupuesto.
7. Preguntas frecuentes sobre due diligence de un CTO
¿Qué es una due diligence técnica de un CTO?
Una due diligence técnica de un CTO es un proceso estructurado de evaluación, generalmente en cuatro a seis sesiones de 90 minutos, donde se valida la profundidad técnica, el liderazgo, la capacidad de stakeholder management y el historial de decisiones del candidato antes de firmar oferta. No se limita a una entrevista: incluye code review en vivo, postmortems reales, referencias 360 grados y validación con el board. Su objetivo es reducir el riesgo de una mala contratación que puede costar entre 18 y 24 meses de productividad del equipo de ingeniería.
¿Cómo puede un founder no técnico evaluar a un CTO?
Un founder no técnico evalúa a un CTO apoyándose en tres pilares: una metodología estructurada de cinco sesiones donde se observa cómo el candidato razona en voz alta, un panel técnico externo de uno o dos asesores que validen la parte profunda de arquitectura y código, y referencias 360 grados con jefes, pares, reportes directos y stakeholders no técnicos. El founder evalúa liderazgo, comunicación y alineamiento estratégico. El panel externo valida lo puramente técnico. Ambos en conjunto reducen el sesgo del founder no técnico.
¿Cuánto dura un proceso completo de due diligence técnica para un CTO?
Un proceso serio de due diligence de un CTO toma entre tres y cinco semanas desde la primera sesión hasta la decisión final. Incluye cinco sesiones de 90 a 120 minutos espaciadas en una o dos semanas, una ronda de referencias 360 con cinco fuentes mínimo, una sesión opcional con el board o inversionistas y un periodo de reflexión de tres a cinco días. Acortarlo bajo dos semanas suele indicar presión política o miedo a perder al candidato, lo que correlaciona con malas contrataciones.
¿Qué red flags debe identificar un founder no técnico al entrevistar a un CTO?
Los red flags principales son: incapacidad de explicar una decisión técnica en lenguaje de negocio, narrativa heroica donde el candidato resolvió todo solo sin acreditar al equipo, ausencia de postmortems o aprendizajes de incidentes pasados, defensividad cuando se cuestionan elecciones de arquitectura, falta de claridad sobre métricas de ingeniería como DORA o lead time, y referencias entrantes que no incluyan reportes directos. También es alarmante que el candidato no haga preguntas de negocio o no muestre interés por el modelo financiero de la empresa.
¿Sirve un CTO interim antes de un CTO definitivo?
Un CTO interim aporta valor cuando la empresa todavía no tiene claridad estratégica sobre el rol, cuando hay urgencia por un incidente reciente o cuando el equipo de ingeniería está sin liderazgo por más de seis semanas. Un interim típicamente firma de tres a nueve meses, estabiliza el área, documenta procesos y deja preparado el perfil real que necesita la empresa. La inversión es mayor por mes que un fijo, pero evita una contratación apresurada de un definitivo bajo presión. No reemplaza la due diligence, solo gana tiempo para hacerla bien.
¿Qué preguntas técnicas debe hacer un founder no técnico a un candidato a CTO?
Cuatro preguntas que funcionan sin conocimiento técnico profundo: uno, describe la peor decisión técnica de los últimos veinticuatro meses y qué aprendiste. Dos, cuéntame un incidente de producción donde tu equipo fallara y cómo lo gestionaste con el resto de la compañía. Tres, cómo decides cuándo construir versus comprar versus integrar. Cuatro, qué métricas de ingeniería reportarías al board mensualmente y por qué. Las respuestas revelan madurez, accountability, criterio de inversión y comunicación ejecutiva sin necesidad de evaluar código.
¿Cuántas referencias se deben pedir para un CTO?
El mínimo razonable son cinco referencias para un CTO: un CEO o founder al que reportó, un par del C-level como un CFO o COO, dos reportes directos del equipo de ingeniería (idealmente un manager y un IC senior), y un stakeholder no técnico como un líder de producto o ventas. Las referencias 360 grados detectan patrones que una sola fuente nunca revela: estilo de delegación, manejo de conflicto, accountability ante errores, capacidad de mentoría real. Menos de cinco referencias entrega un retrato incompleto y aumenta el riesgo de bad hire en un cargo donde el error cuesta dieciocho a veinticuatro meses de productividad.
¿Cómo se hace un code review a un CTO si el founder no programa?
El founder no técnico no hace el code review directamente. Contrata a un asesor técnico externo, un Staff Engineer o un VP Engineering amigo de la red, que se siente con el candidato 90 minutos y revise: un repositorio o snippet propio del candidato, una decisión de arquitectura documentada y una sesión de pair programming sobre un problema medio. El founder asiste a la sesión solo como observador para evaluar cómo el candidato explica, cómo recibe feedback y si baja a lenguaje no técnico. El veredicto técnico lo da el asesor; el veredicto de comunicación lo da el founder.
¿Cuánto cuesta una mala contratación de CTO?
Una mala contratación de CTO en una startup o scale-up cuesta entre veinticuatro y cuarenta millones de pesos chilenos directos: salario pagado durante seis a nueve meses, indemnización, costo de búsqueda nueva y posible reemplazo. Pero el costo indirecto es mayor: rotación de ingenieros senior que renuncian con el CTO equivocado, decisiones de arquitectura que cuesta entre seis y dieciocho meses revertir, atraso en el roadmap y pérdida de confianza del board. En suma, una mala contratación de CTO equivale fácilmente a dieciocho a veinticuatro meses de productividad del área de ingeniería.
¿Qué diferencia hay entre evaluar a un VP Engineering y a un CTO?
Un VP Engineering es operacional: gestiona managers, ejecuta el roadmap, mantiene velocidad de entrega y profesionaliza procesos. Un CTO es estratégico: define la visión técnica, decide build versus buy, levanta capital con el CEO, evalúa adquisiciones y representa a tecnología frente al board. Evaluar un VP de Ingeniería pone más peso en la sesión 2 (code review y arquitectura) y la sesión 3 (liderazgo y org design). Evaluar un CTO pone más peso en la sesión 1 (visión técnica y mapa de decisiones) y la sesión 4 (stakeholder management con board). Ambos roles requieren due diligence, pero el balance cambia.
Basado en más de 100 búsquedas C-level tech gestionadas por IT Workers entre 2024 y 2026, incluyendo procesos de CTO, VP Engineering, Head of Data y Engineering Manager en banca, fintech, retail digital, healthtech, minería y SaaS B2B. Los datos numéricos del artículo son agregados anónimos basados en mandatos reales.
¿Estás por contratar a tu próximo CTO?
IT Workers entrega shortlist calificado de candidatos C-level tech con due diligence completa en 7 a 14 días hábiles. Success fee, garantía contractual de 90 días, pago solo al contratar. Agenda esta semana una conversación de 20 minutos para ver si tu búsqueda aplica.
Solicitar shortlist CTO WhatsApp directo