El Verdadero Coste de una Mala Contratación Técnica
La estimación estándar de la industria dice que una mala contratación cuesta entre 1,5x y 3x el salario anual del puesto. Si contratas a un ingeniero senior a 80.000 euros al año y no funciona, estás mirando un agujero de entre 120.000 y 240.000 euros.
Pero esa cifra solo captura lo visible. La parte que puedes poner en una hoja de cálculo. Lo que realmente destruye a una startup no es el dinero que se fue — es el tiempo que no vuelve y el daño que dejó atrás.
Los costes visibles: lo que puedes calcular
Empecemos por lo obvio, porque ya duele bastante:
- Salario acumulado. Los meses que pagaste antes de darte cuenta del error. Normalmente 3-6 meses.
- Costes de reclutamiento. Si usaste una agencia, pagaste entre un 15% y un 25% del salario anual. Si lo hiciste internamente, el tiempo invertido en screening, entrevistas y negociación.
- Indemnización. Dependiendo del país y del contrato, puede ser desde un mes hasta varios meses de salario.
- Coste de reemplazo. Vuelves a empezar el proceso. Otra ronda de publicar ofertas, filtrar CVs, hacer entrevistas técnicas, negociar. Si tienes suerte, 2-3 meses. Si no, 6.
Suma todo esto y llegas fácilmente a esa estimación de 1,5-3x. Pero aquí es donde la mayoría de análisis se detienen. Y es donde empieza el verdadero daño.
Los costes invisibles: lo que no aparece en ninguna hoja de cálculo
Deuda técnica heredada
Un mal ingeniero no solo no construye lo que debería. Construye mal lo que toca. Código sin tests, arquitectura que no escala, dependencias innecesarias, abstracciones que nadie entiende. Cuando se va, ese código queda. Y alguien tiene que lidiar con él.
He visto casos donde un ingeniero estuvo 4 meses en una startup y dejó una base de código que el siguiente senior tardó 6 semanas en reescribir antes de poder avanzar. Esas 6 semanas son puro coste hundido — no estás construyendo features nuevas, estás deshaciendo el trabajo de alguien que se fue.
Daño a la moral del equipo
Esto es lo que menos se mide y más impacto tiene. Cuando un miembro del equipo no rinde, el resto lo sabe. Antes que tú, normalmente. Y cada semana que pasa sin que hagas algo al respecto, tu credibilidad como líder se erosiona.
Los buenos ingenieros no quieren trabajar con malos ingenieros. Si tardas demasiado en actuar, el riesgo no es solo perder al que no funciona — es que los que sí funcionan empiecen a buscar otro sitio.
Deadlines incumplidos
Contrataste a ese ingeniero porque necesitabas entregar algo. Un feature crítico, una integración, un MVP. Cada mes que pasa con alguien que no ejecuta es un mes de retraso en tu producto. En una startup, eso puede significar:
- Perder una ventana de mercado. Tu competidor lanzó primero.
- Perder la confianza de inversores. No cumpliste el roadmap que presentaste en la ronda.
- Perder clientes. Prometiste una feature para Q1 y no llegó.
Pérdida de conocimiento institucional
Cuando alguien se va — aunque sea alguien que no rendía bien — se lleva contexto. Decisiones que tomó, conversaciones que tuvo con otros miembros del equipo, entendimiento del dominio del negocio. Parte de ese contexto se pierde para siempre. El siguiente ingeniero empieza con un déficit de información que tarda semanas en compensar.
La línea temporal del desastre
Pongamos números al tiempo:
- Meses 0-3: Contratación. Publicas la oferta, filtras, entrevistas, negociar, onboarding. Si todo va bien, 2-3 meses. Si el mercado está caliente — y en tech lo está — pueden ser 4-6.
- Meses 3-6: Luna de miel. El nuevo ingeniero se incorpora. Los primeros meses son de ramp-up. Es normal que no produzca al 100%. Le das el beneficio de la duda.
- Meses 6-9: La sospecha. Empiezas a ver señales. Code reviews que vuelven con muchos comentarios. Tareas que se retrasan. Otros ingenieros que empiezan a quejarse en privado. Pero piensas: "Quizá necesita más tiempo."
- Meses 9-11: La certeza. Ya sabes que no funciona. Pero ahora tienes que gestionar la salida. Conversaciones difíciles, documentar el rendimiento, proceso de offboarding.
- Meses 11-14: De vuelta al principio. Vuelves a contratar.
Resultado: hasta 14 meses perdidos. Para una startup que intenta llegar a product-market fit, eso puede ser letal.
Por qué pasa: los errores más comunes
Las malas contrataciones no son mala suerte. Son el resultado de un proceso roto. Estos son los errores que veo con más frecuencia:
Contratar con urgencia, no con criterio
"Necesitamos un backend developer para ayer." Suena familiar. La presión por entregar hace que bajes el listón. Aceptas al candidato que está "bien" en lugar de esperar al que es "excelente." Ese atajo siempre sale más caro.
Confiar demasiado en el CV
Un CV impresionante no garantiza nada. He entrevistado a candidatos con experiencia en Google y Amazon que no podían resolver un problema de diseño de sistemas básico. Y he visto ingenieros de empresas que no conocías que escribían código impecable. El CV te dice dónde ha estado alguien. No te dice cómo trabaja.
No hacer evaluación técnica real
Una conversación de 30 minutos no es una evaluación técnica. Si no estás haciendo code reviews de código real, ejercicios de diseño de sistemas, o al menos un pair programming session, estás adivinando. Y adivinar con contrataciones de 60.000-100.000 euros al año es un riesgo absurdo.
Evaluar entrevista, no producción
Hay gente que entrevista increíblemente bien y produce mediocremente. Y viceversa. Si tu proceso selecciona por capacidad de entrevista en lugar de capacidad de ejecución, vas a optimizar para lo incorrecto.
Cómo prevenirlo: el framework que funciona
No hay garantía del 100%, pero puedes reducir drásticamente el riesgo:
1. Vetting técnico riguroso. No solo algoritmos y estructuras de datos. Evaluación de código real. ¿Cómo estructura un proyecto? ¿Cómo maneja errores? ¿Cómo piensa sobre testing? ¿Puede explicar decisiones de arquitectura que tomó en proyectos anteriores?
2. Evaluación por ingenieros, no por recruiters. Un recruiter puede evaluar soft skills y fit cultural. No puede evaluar si alguien sabe diseñar un sistema de colas distribuido. Tus ingenieros senior — o tu CTO — deben estar en el proceso.
3. Período de prueba real. No un período de prueba donde miras si la persona "encaja." Un período donde le asignas trabajo real con deliverables concretos y evalúas la calidad del output. 2-4 semanas suelen ser suficientes para saber si alguien ejecuta de verdad.
4. Referencias técnicas, no solo profesionales. No llames solo a su antiguo jefe. Habla con alguien que haya revisado su código o trabajado en el mismo equipo técnico. Las preguntas que importan: "¿Volverías a trabajar con esta persona? ¿Le darías un proyecto crítico?"
Cómo lo resolvemos en Conectia
Todo lo anterior requiere tiempo, expertise técnica, y un proceso bien definido. La mayoría de startups en fase temprana no tienen las tres cosas. Tienen prisa, tienen un founder técnico que ya está al límite de su capacidad, y no tienen un proceso de hiring probado.
Es exactamente por eso que montamos Conectia. Nuestro proceso de vetting tiene una tasa de aceptación del 8%. No es un filtro de CV — es una evaluación técnica liderada por CTOs con experiencia en producción. Evaluamos código real, capacidad de diseño de sistemas, y experiencia demostrable en entornos de startup.
Si un ingeniero no funciona, lo reemplazamos en los primeros 30 días sin coste adicional. No porque esperemos que pase — nuestra tasa de retención es del 95% — sino porque entendemos que para un founder, la confianza en el proceso importa tanto como el resultado.
El coste de una mala contratación no es un número en una hoja de cálculo. Es tiempo que no recuperas, código que tienes que reescribir, y moral de equipo que tarda meses en reconstruirse. La mejor inversión que puedes hacer no es contratar rápido — es contratar bien.
¿Cansado de procesos de contratación que no filtran de verdad? Habla con un CTO — ingenieros senior pre-validados con garantía de reemplazo en 30 días.
