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 guia condensa el plan de onboarding de 90 dias que vemos funcionar consistentemente en empresas tech chilenas que retienen sobre el 90% de sus contrataciones senior al cumplir 1 ano.
1. Por que los primeros 90 dias predicen la retencion al ano
Los primeros 90 dias funcionan como una ventana de validacion 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 dias, el siguiente trimestre el developer ya esta postulando a otras posiciones, aunque oficialmente no haya renunciado.
Retencion al ano segun calidad del onboarding tech
El grafico muestra una realidad clara: las empresas con onboarding estructurado y monitoreado retienen al 90%+ al ano; las que improvisan retienen el 60-70%. La diferencia es enorme cuando se traduce a costos: una empresa que contrata 10 developers al ano 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 dia 1: lo que decide los primeros 90 dias
Un buen onboarding empieza antes del primer dia, no el primer dia. La fase de pre-onboarding (entre la firma de la oferta y el primer dia) 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 dia
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 via 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 tecnico listo el dia 0
Computador configurado, accesos a Slack/Teams, GitHub/GitLab, repositorios, herramientas de monitoreo, dashboards, ambientes de desarrollo. Que el dia 1 el developer pueda hacer un primer commit (aunque sea de prueba) en menos de 4 horas. Si el dia 1 se va en pelear con IT por accesos, la senal 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 dia 1.
Plan de 30/60/90 dias documentado
Antes del primer dia, el manager directo prepara objetivos claros y medibles para los dias 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 tecnica para X". Lo entrega el dia 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 orientacion
- 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 tecnica
- 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 pequeno, feature pequena)
- 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 pequeno)
- 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 satisfaccion del primer mes
Senal de alerta del dia 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 dia 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 pequeno (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 tecnicas 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 dia 60
| Hito dia 60 | Indicador positivo | Senal 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 vision 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 ano 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: vision a 12 meses
- Conversacion explicita con manager sobre objetivos a 6 y 12 meses
- Mapeo de plan de crecimiento profesional (carrera tecnica 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 ano
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 pequenas y bien definidas, pair programming frecuente las primeras 8 semanas, feedback semanal del manager, claridad absoluta en expectativas, validacion 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 tecnico claro, autonomia creciente desde semana 3, oportunidad de proponer mejoras, feedback bidireccional. Necesita ver que sus aportes tecnicos son valorados.
Riesgos: sentirse subutilizado, no tener claridad sobre crecimiento.
Que necesita: contexto completo del negocio desde dia 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 tecnico real, ser tratado como "el nuevo" mas alla del mes 1.
Que necesita: claridad sobre el equipo que lidera, autoridad real para tomar decisiones tecnicas y de proceso desde semana 4, acceso a metricas del equipo, sponsorship visible del CTO, espacio para hacer cambios sin friccion politica. Si solo "observa" durante 2 meses, pierde credibilidad con su equipo.
Riesgos: ambiguedad de rol, falta de autoridad real, no entender la cultura politica 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 clasica que indica un onboarding que tomara meses. Empresas con buena retencion documentan al menos: arquitectura general, decisiones tecnicas 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 energia 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 senal 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 decision. 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 tecnologias modernas" / dia 1: stack legacy del 2014. "Tenemos cultura de autonomia" / dia 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 dia 30/60/90, y revisiones formales de progreso. Lo que no se mide no se mejora.
8. Las 4 metricas que definen exito del onboarding tech
| Metrica | Como medir | Target | Senal de alerta |
|---|---|---|---|
| Tiempo a primer PR mergeado | Dias desde dia 1 al merge | 3-5 dias | +10 dias |
| Tiempo a primer deploy productivo independiente | Dias desde dia 1 al deploy | 15-25 dias | +45 dias |
| NPS interno dia 30/60/90 | Survey simple | 8+ /10 | Menos de 7 /10 |
| Retencion al dia 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 exito tienen reteniendo perfiles senior trabajan con sus partners de busqueda en check-ins post-contratacion: el headhunter habla con el candidato a los 30 y 60 dias para validar adaptacion, levantar alertas tempranas y dar feedback al cliente sin pasar por canales internos. Es un canal de comunicacion adicional que ayuda a detectar problemas antes de que se conviertan en renuncias.
En IT Workers hacemos esto sistematicamente: a los 30 dias 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 desempeno. 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 seleccion. Un candidato bien evaluado tecnicamente, con expectativas alineadas y referencias chequeadas, llega al dia 1 con energia para integrarse. Un candidato apurado, con dudas sin resolver y compensacion ambigua, llega al dia 1 ya cuestionando su decision.
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-contratacion en los primeros 90 dias para asegurar integracion exitosa. Shortlist en 4 dias habiles.
Agenda disponible esta semana
Solicitar candidatos