El error mas costoso que comete una empresa tech en Chile no esta en la entrevista ni en la oferta: esta en lo que pasa despues de que el candidato firma. La narrativa de "ya esta contratado, ahora a producir" es la que mas churn temprano genera en perfiles tech senior. Y el churn temprano es brutal: estimaciones internacionales aplicables a Chile ponen el costo de perder un Senior Engineer en los primeros 6 meses entre 1,5 y 2 veces su sueldo anual, sumando proceso de busqueda, tiempo del equipo invertido, productividad perdida e impacto en moral.
Como firma de headhunting tech, en IT Workers vemos el otro lado tambien: developers que aceptaron una oferta y a los 3 meses ya estan respondiendo a recruiters de la competencia. Cuando indagamos por que, la respuesta casi siempre es la misma: "no me sentia incorporado, no estaba claro que se esperaba de mi, no veia para donde iba". Esta guía condensa el plan de onboarding de 90 días que vemos funcionar consistentemente en empresas tech chilenas que retienen sobre el 90% de sus contrataciones senior al cumplir 1 año.
1. Por que los primeros 90 días predicen la retencion al año
Los primeros 90 días funcionan como una ventana de validación mutua. La empresa esta evaluando si el candidato cumple lo que prometio en entrevistas; pero igual de importante (y a menudo ignorado), el candidato esta validando si la empresa cumple lo que vendio en el proceso. Si esas dos validaciones no convergen positivamente en 90 días, el siguiente trimestre el developer ya esta postulando a otras posiciones, aunque oficialmente no haya renunciado.
Retencion al año segun calidad del onboarding tech
El grafico muestra una realidad clara: las empresas con onboarding estructurado y monitoreado retienen al 90%+ al año; las que improvisan retienen el 60-70%. La diferencia es enorme cuando se traduce a costos: una empresa que contrata 10 developers al año y tiene mal onboarding pierde 3-4 personas, lo que en perfiles senior equivale a $300M-$500M CLP en costos directos de reemplazo, sin contar el impacto en velocidad del equipo y proyectos retrasados.
2. Antes del día 1: lo que decide los primeros 90 días
Un buen onboarding empieza antes del primer día, no el primer día. La fase de pre-onboarding (entre la firma de la oferta y el primer día) es donde se previene el "candidato fantasma" (el que firma y se arrepiente antes de empezar) y donde se prepara el terreno para una integracion sin friccion.
Comunicacion semanal hasta el primer día
Si entre la firma y el inicio hay 2-4 semanas, el silencio es enemigo. Empresas que retienen mejor mantienen contacto semanal: bienvenida del CEO/CTO, presentacion del equipo vía video, envio de materiales de pre-lectura (no obligatorios), invitacion a una happy hour del equipo si es presencial. Reduce el riesgo de "contraoferta de ultimo momento" del empleador anterior.
Setup técnico listo el día 0
Computador configurado, accesos a Slack/Teams, GitHub/GitLab, repositorios, herramientas de monitoreo, dashboards, ambientes de desarrollo. Que el día 1 el developer pueda hacer un primer commit (aunque sea de prueba) en menos de 4 horas. Si el día 1 se va en pelear con IT por accesos, la señal es pesima.
Buddy asignado y briefeado
Un Senior o Tech Lead del mismo equipo asignado formalmente como buddy del nuevo, con tiempo bloqueado en su agenda durante el primer mes. El buddy debe haber leido el perfil, conocer el rol y entender que se espera del nuevo. No improvisar buddies en el día 1.
Plan de 30/60/90 días documentado
Antes del primer día, el manager directo prepara objetivos claros y medibles para los días 30, 60 y 90. No metas vagas como "integrarse al equipo" sino objetivos concretos: "merge de 5 PRs, 1 deploy productivo independiente, presentacion de propuesta técnica para X". Lo entrega el día 1.
3. Dias 1-30: contexto, conexiones y primer impacto
El primer mes es de absorber contexto: como funciona el negocio, quien decide que, donde estan los datos, como se despliega, cuales son las prioridades. Pero atencion: contexto sin entregables genera ansiedad en perfiles senior. La regla que vemos funcionar es 70% absorber/30% producir en las primeras 4 semanas.
Semana 1: bienvenida y orientación
- Dia 1: bienvenida formal con manager + buddy. Tour por herramientas, repositorios, documentacion clave
- Dia 2-3: sesiones 1:1 con stakeholders clave (Product, Design, otros tech leads relacionados)
- Dia 4-5: primer commit no critico (configuracion, bugfix menor, mejora de docs). Objetivo: validar que el setup funciona
- Cierre semana: 30 min con manager para validar comodidad, despejar dudas, ajustar expectativas
Semana 2: inmersion técnica
- Pair programming con buddy en una tarea real del equipo
- Lectura de codigo: revisar PRs recientes para entender estilo y convenciones
- Documentar (en publico) preguntas y aprendizajes en un canal/doc dedicado. Sirve a futuros nuevos
- Sesion con DevOps para entender pipelines de despliegue
- Primer PR independiente del nuevo, revisado por buddy
Semana 3: primer impacto visible
- Asignacion de un ticket "starter" relevante pero no critico (mejora interna, refactor pequeño, feature pequeña)
- Participacion activa en stand-ups con updates concretos
- Primera presentacion en demo del equipo si aplica
- Sesion 1:1 con manager: que esta funcionando, que no, ajustes
Semana 4: cierre del primer ciclo
- Primer despliegue productivo independiente (puede ser pequeño)
- Review formal del plan 30/60/90: ajustes si aplica
- Sesion de feedback bidireccional: manager da feedback al nuevo, el nuevo da feedback al onboarding hasta ahora
- NPS interno o survey de satisfacción del primer mes
Señal de alerta del día 30: si el nuevo developer aun no tiene un PR mergeado, no ha hecho un deploy o no tiene un proyecto asignado claramente, hay un problema de onboarding. No del developer, del proceso. La intervencion del manager debe ser inmediata.
4. Dias 31-60: autonomia creciente y contribucion productiva
El segundo mes es donde el developer pasa de ser "el nuevo" a ser "uno mas del equipo". Si esta transicion no ocurre alrededor del día 45-50, hay riesgo de que se sienta perpetuamente como observador externo. La autonomia debe crecer aceleradamente.
Semanas 5-6: ownership de un componente
- Asignacion formal de un componente, modulo o area de la que el nuevo es owner principal
- Liderazgo de su primer proyecto pequeño (1-2 semanas) end-to-end
- Empieza a hacer code reviews a otros del equipo (no solo recibirlos)
- Buddy reduce su rol activo: pasa de "presente diariamente" a "disponible si necesitas"
Semanas 7-8: contribucion a decisiones
- Participacion en decisiones técnicas del equipo (arquitectura, prioridades de roadmap)
- Propuesta de al menos una mejora al proceso o stack basada en su perspectiva externa fresca
- 1:1 con CTO o equivalente si no es su manager directo
- Review formal del avance vs plan 30/60/90 al cumplir día 60
| Hito día 60 | Indicador positivo | Señal de alerta |
|---|---|---|
| Productividad codigo | 10+ PRs mergeados | Menos de 5 PRs |
| Despliegues productivos | 3+ deploys independientes | Aun depende de buddy |
| Participacion en decisiones | Propone mejoras activamente | Solo ejecuta lo asignado |
| Relaciones | Trabaja directo con product/design | Solo interactua con su manager |
| Autoreporte (NPS) | 8+ /10 | Menos de 7 /10 |
El factor que mas mueve la retencion temprana no es el sueldo, es sentir que se esta haciendo trabajo significativo desde temprano. Por eso contratar al perfil correcto importa mas que cualquier plan de onboarding.
Solicitar candidatos evaluados tecnicamente5. Dias 61-90: integracion completa y visión a largo plazo
El tercer mes es donde el developer cierra la transicion de "nuevo en proceso de adaptacion" a "miembro pleno del equipo con perspectiva propia". Es tambien el momento de plantar la conversacion sobre crecimiento, lo que muchas empresas posponen al primer año y pierden engagement crucial.
Semanas 9-10: liderazgo de iniciativa
- El developer lidera al menos una iniciativa con visibilidad mas alla de su equipo inmediato
- Mentorea o ayuda a un miembro mas junior del equipo (acelera sentido de pertenencia)
- Documenta procesos o aprendizajes propios para futuros nuevos del equipo
- Si aplica, presenta en una demo de toda la organizacion tech
Semanas 11-12: visión a 12 meses
- Conversacion explicita con manager sobre objetivos a 6 y 12 meses
- Mapeo de plan de crecimiento profesional (carrera técnica vs management si aplica)
- Formalizacion de areas de especializacion y responsabilidades a futuro
- Si aplica, conversacion sobre equity, bonos o ajustes salariales en el ciclo del primer año
Dia 90: review formal y survey
- Review formal del manager con feedback bidireccional
- Survey detallado del onboarding completo: que funciono, que no, que cambiar
- Ajuste de plan a 12 meses con metricas claras y conversacion sobre desarrollo
- Reconocimiento explicito (publico si corresponde) de la integracion exitosa
6. Onboarding senior vs junior: las diferencias criticas
Tratar a un Senior Engineer como junior es una de las causas mas frecuentes de churn temprano que vemos en perfiles experimentados que dejan empresas a los 4-6 meses. Cada nivel requiere un enfoque distinto:
Que necesita: tareas pequeñas y bien definidas, pair programming frecuente las primeras 8 semanas, feedback semanal del manager, claridad absoluta en expectativas, validación explicita de avances. Tolera (y aprecia) microgestion benevola.
Riesgos: sentirse abandonado, asumir tareas demasiado grandes que generan parálisis, no atreverse a preguntar.
Que necesita: contexto técnico claro, autonomia creciente desde semana 3, oportunidad de proponer mejoras, feedback bidireccional. Necesita ver que sus aportes técnicos son valorados.
Riesgos: sentirse subutilizado, no tener claridad sobre crecimiento.
Que necesita: contexto completo del negocio desde día 1, acceso directo a CTO/stakeholders sin intermediarios, problemas dificiles desde semana 2-3, libertad para cuestionar el status quo, conversacion temprana sobre carrera/equity. La microgestion los ahuyenta.
Riesgos: sentirse infrautilizado (causa #1 de salida), no tener desafio técnico real, ser tratado como "el nuevo" mas alla del mes 1.
Que necesita: claridad sobre el equipo que lidera, autoridad real para tomar decisiones técnicas y de proceso desde semana 4, acceso a metricas del equipo, sponsorship visible del CTO, espacio para hacer cambios sin friccion política. Si solo "observa" durante 2 meses, pierde credibilidad con su equipo.
Riesgos: ambiguedad de rol, falta de autoridad real, no entender la cultura política interna.
7. Los 7 errores que generan churn temprano (y como evitarlos)
"Saltar" el onboarding por urgencia productiva
"Tenemos un release esta semana, ponete a programar". Suena pragmatico, es destructivo. Sin contexto, el nuevo produce codigo subobtimo que el equipo despues debe reescribir, generando friccion y sensacion de fracaso temprano. Solucion: bloquear onboarding incluso si hay urgencia. Las semanas perdidas se recuperan con creces.
Documentacion inexistente o desactualizada
"La documentacion esta en Confluence... pero la verdad es que esta vieja, mejor preguntale a [persona X]". Sentencia clásica que indica un onboarding que tomara meses. Empresas con buena retencion documentan al menos: arquitectura general, decisiones técnicas pasadas (ADRs), runbooks de incidentes y onboarding paso a paso.
No tener buddy formal asignado
"Cualquiera del equipo te puede ayudar" se traduce a "nadie te ayudara consistentemente". Sin un buddy formal con tiempo bloqueado, el nuevo gasta energía averiguando a quien preguntar. Solucion: buddy formal por escrito, con expectativas claras de tiempo (30 min diarios primera semana, 1 hora semanal a partir de la semana 4).
Asignar tareas demasiado simples a perfiles senior
"Por seguridad, te empezamos con bugs simples para que conozcas el codigo". Para un Senior es señal de desconfianza. La integracion a traves de problemas reales (con buddy disponible) es mas efectiva. CTOs y leads que sufren mas churn senior son los que tratan a senior como junior.
Ausencia del manager en las primeras semanas
"Yo viajo estas dos semanas, despues nos juntamos". Si el manager no esta presente en las primeras 2-3 semanas, el nuevo se siente abandonado y empieza a cuestionar su decisión. Si el manager debe ausentarse, debe nombrar un proxy explicito y formal con autoridad real.
Promesas de la entrevista que no se cumplen en los hechos
"Vas a trabajar con tecnologías modernas" / día 1: stack legacy del 2014. "Tenemos cultura de autonomia" / día 1: micromanagement intenso. La discrepancia entre lo prometido y la realidad es la causa #1 de churn entre los meses 3 y 6. Solucion: alinear discurso de venta con realidad operacional desde el principio.
No medir nada del onboarding
Empresas sin metricas de onboarding no saben cuando hay un problema hasta que el developer renuncia. Solucion: tracking simple de tiempo al primer PR, primer deploy, NPS día 30/60/90, y revisiones formales de progreso. Lo que no se mide no se mejora.
8. Las 4 metricas que definen éxito del onboarding tech
| Metrica | Como medir | Target | Señal de alerta |
|---|---|---|---|
| Tiempo a primer PR mergeado | Dias desde día 1 al merge | 3-5 días | +10 días |
| Tiempo a primer deploy productivo independiente | Dias desde día 1 al deploy | 15-25 días | +45 días |
| NPS interno día 30/60/90 | Survey simple | 8+ /10 | Menos de 7 /10 |
| Retencion al día 180 | % activo a 6 meses | 95%+ | Menos de 85% |
Estas metricas deben ser tracked sistematicamente y revisadas trimestralmente a nivel de tech leadership. Si una metrica se desvia, la accion correctiva debe ser inmediata: ajuste del plan, intervencion del manager, o conversacion 1:1 con el nuevo. Esperar a que el problema se "resuelva solo" es la receta para perder a la persona.
9. El rol del headhunter en el onboarding
Una buena firma de headhunting tech no termina su trabajo cuando el candidato firma. Las empresas que mas éxito tienen reteniendo perfiles senior trabajan con sus partners de busqueda en check-ins post-contratación: el headhunter habla con el candidato a los 30 y 60 días para validar adaptacion, levantar alertas tempranas y dar feedback al cliente sin pasar por canales internos. Es un canal de comunicación adicional que ayuda a detectar problemas antes de que se conviertan en renuncias.
En IT Workers hacemos esto sistematicamente: a los 30 días contactamos al candidato para validar que la realidad coincide con lo prometido en el proceso, y a los 60-90 al cliente para feedback sobre el desempeño. Cuando aparece una desalineacion, intervenimos antes de que escale. Es parte del valor de un reclutamiento IT especializado vs consultora RRHH generalista.
El mejor onboarding empieza antes de que el candidato firme: en la calidad del proceso de selección. Un candidato bien evaluado tecnicamente, con expectativas alineadas y referencias chequeadas, llega al día 1 con energía para integrarse. Un candidato apurado, con dudas sin resolver y compensación ambigua, llega al día 1 ya cuestionando su decisión.
Tu empresa necesita contratar tech con alta probabilidad de retencion?
IT Workers es la firma de headhunting tech especializada en Chile. Evaluamos candidatos tecnicamente, validamos fit cultural, y hacemos seguimiento post-contratación en los primeros 90 días para asegurar integracion exitosa. Shortlist en 4 días habiles.
Agenda disponible esta semana
Solicitar candidatos