El error más costoso que comete una empresa tech en Chile no esta en la entrevista ni en la oferta: esta en lo que pasa después de que el candidato firma. La narrativa de "ya esta contratado, ahora a producir" es la que más 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 también: 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 retención 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.
Retención al año según 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 integración sin fricción.
Comunicación 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, presentación del equipo vía video, envio de materiales de pre-lectura (no obligatorios), invitación a una happy hour del equipo si es presencial. Reduce el riesgo de "contraoferta de último 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, presentación 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 atención: 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, documentación clave
- Dia 2-3: sesiones 1:1 con stakeholders clave (Product, Design, otros tech leads relacionados)
- Dia 4-5: primer commit no crítico (configuración, 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: inmersión técnica
- Pair programming con buddy en una tarea real del equipo
- Lectura de código: revisar PRs recientes para entender estilo y convenciones
- Documentar (en público) preguntas y aprendizajes en un canal/doc dedicado. Sirve a futuros nuevos
- Sesión con DevOps para entender pipelines de despliegue
- Primer PR independiente del nuevo, revisado por buddy
Semana 3: primer impacto visible
- Asignación de un ticket "starter" relevante pero no crítico (mejora interna, refactor pequeño, feature pequeña)
- Participación activa en stand-ups con updates concretos
- Primera presentación en demo del equipo si aplica
- Sesión 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
- Sesión 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 intervención del manager debe ser inmediata.
4. Dias 31-60: autonomia creciente y contribución productiva
El segundo mes es donde el developer pasa de ser "el nuevo" a ser "uno más del equipo". Si esta transición 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
- Asignación formal de un componente, modulo o área 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: contribución a decisiones
- Participación 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 código | 10+ PRs mergeados | Menos de 5 PRs |
| Despliegues productivos | 3+ deploys independientes | Aun depende de buddy |
| Participación 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 más mueve la retención temprana no es el sueldo, es sentir que se esta haciendo trabajo significativo desde temprano. Por eso contratar al perfil correcto importa más que cualquier plan de onboarding.
Solicitar candidatos evaluados técnicamente5. Dias 61-90: integración completa y visión a largo plazo
El tercer mes es donde el developer cierra la transición de "nuevo en proceso de adaptación" a "miembro pleno del equipo con perspectiva propia". Es también el momento de plantar la conversación 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 más alla de su equipo inmediato
- Mentorea o ayuda a un miembro más 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 organización tech
Semanas 11-12: visión a 12 meses
- Conversación explicita con manager sobre objetivos a 6 y 12 meses
- Mapeo de plan de crecimiento profesional (carrera técnica vs management si aplica)
- Formalización de áreas de especialización y responsabilidades a futuro
- Si aplica, conversación 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 métricas claras y conversación sobre desarrollo
- Reconocimiento explicito (público si corresponde) de la integración exitosa
6. Onboarding senior vs junior: las diferencias críticas
Tratar a un Senior Engineer como junior es una de las causas más 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 difíciles desde semana 2-3, libertad para cuestionar el status quo, conversación 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" más 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 métricas del equipo, sponsorship visible del CTO, espacio para hacer cambios sin fricción 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 código subobtimo que el equipo después debe reescribir, generando fricción y sensación de fracaso temprano. Solución: bloquear onboarding incluso si hay urgencia. Las semanas perdidas se recuperan con creces.
Documentación inexistente o desactualizada
"La documentación 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 retención 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. Solución: 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 código". Para un Senior es señal de desconfianza. La integración a traves de problemas reales (con buddy disponible) es más efectiva. CTOs y leads que sufren más churn senior son los que tratan a senior como junior.
Ausencia del manager en las primeras semanas
"Yo viajo estas dos semanas, después 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. Solución: alinear discurso de venta con realidad operacional desde el principio.
No medir nada del onboarding
Empresas sin métricas de onboarding no saben cuando hay un problema hasta que el developer renuncia. Solución: 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 métricas 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 |
| Retención al día 180 | % activo a 6 meses | 95%+ | Menos de 85% |
Estas métricas deben ser tracked sistematicamente y revisadas trimestralmente a nivel de tech leadership. Si una métrica se desvia, la acción correctiva debe ser inmediata: ajuste del plan, intervención del manager, o conversación 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 más é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 adaptación, 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 desalineación, 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 técnicamente, 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 retención?
IT Workers es la firma de headhunting tech especializada en Chile. Evaluamos candidatos técnicamente, validamos fit cultural, y hacemos seguimiento post-contratación en los primeros 90 días para asegurar integración exitosa. Shortlist en 4 días habiles.
Agenda disponible esta semana
Solicitar candidatos