Onboarding de programadores: guía práctica para los primeros 30 días

Contratar a un buen programador cuesta semanas y mucho dinero. Perderlo a los dos meses porque nadie preparó su llegada cuesta todavía más. El onboarding de programadores es la parte del proceso que empieza después de la firma, y es donde muchas empresas improvisan. Esta guía te da un plan concreto para los primeros 30 días: qué preparar antes de que llegue, qué hacer la primera semana y qué errores evitar.

Por qué el onboarding de programadores es distinto

Un desarrollador no solo necesita conocer la empresa: necesita entender un código que no escribió, unas herramientas concretas y unas decisiones técnicas que rara vez están documentadas. Si ese contexto no se le da de forma ordenada, sus primeras semanas se convierten en frustración (para él) y en coste (para ti). Los datos de rotación en perfiles tech son claros: una mala incorporación es una de las causas principales de bajas en el primer año, y cada salida prematura equivale a varios meses de sueldo entre selección, formación y productividad perdida.

Antes de su primer día: la semana de preparación

El onboarding empieza antes de que la persona entre por la puerta. Deja listo esto con al menos tres o cuatro días de margen:

• Accesos y cuentas: correo, repositorios, gestor de tareas, entornos de desarrollo y producción, VPN y cualquier herramienta interna. Nada mata más la ilusión que pasarse el primer día esperando permisos.
• Equipo configurado: portátil con el entorno de desarrollo instalado o una guía de instalación probada por otra persona del equipo hace menos de un mes.
• Documentación mínima: cómo levantar el proyecto en local, arquitectura general en una página, convenciones de código y cómo se despliega. No hace falta una wiki perfecta; hace falta que funcione.
• Una persona de referencia: asigna un «buddy» técnico que sepa que lo es y tenga horas reservadas para acompañar la primera semana.
• Calendario de la primera semana: reuniones de presentación ya agendadas, con nombres y objetivos claros.

Primera semana: contexto antes que producción

El error más común es esperar código útil desde el día dos. La primera semana es para absorber contexto: producto, clientes, arquitectura y formas de trabajar. Funciona bien este orden:

• Día 1: bienvenida, accesos comprobados, tour por el producto desde fuera (como lo ve un usuario) y reunión con su buddy.
• Días 2-3: levantar el proyecto en local y hacer el primer despliegue a un entorno de pruebas. Si no lo consigue, el problema es de la documentación, no suyo.
• Días 4-5: primera tarea pequeña y acotada: un bug menor o una mejora sencilla que toque una sola parte del sistema. El objetivo no es la tarea; es completar el ciclo entero de trabajo (rama, revisión, despliegue).

Semanas 2 a 4: de tareas acotadas a responsabilidad real

A partir de la segunda semana, aumenta la complejidad de forma progresiva. Tres prácticas que marcan la diferencia:

• Revisión de código como enseñanza, no como examen: explica el «porqué» de las convenciones en los comentarios. Un programador nuevo que entiende las razones se equivoca menos y pregunta mejor.
• Una reunión semanal de seguimiento: 30 minutos para desbloquear dudas y ajustar expectativas en ambos sentidos. No esperes a la reunión de los 3 meses para descubrir un problema.
• Objetivos claros a 30 días: define qué esperas que sea capaz de hacer solo al terminar el primer mes y díselo. La ambigüedad genera inseguridad y malentendidos.

Los 5 errores que más dinero cuestan

• Improvisar la bienvenida: sin accesos, sin plan y con el equipo «ya te contará alguien».
• Asignar una tarea crítica la primera semana para «ver de qué es capaz».
• Documentación obsoleta que contradice lo que hace el equipo.
• No presentar al negocio: un programador que no sabe quién usa el producto toma peores decisiones técnicas.
• Dar por terminado el onboarding a la semana: la curva real de autonomía en un código nuevo son de 2 a 3 meses.

Cuándo tiene sentido pedir ayuda externa

Un buen onboarding empieza mucho antes: con una buena selección. Si el perfil no es el adecuado, ningún plan de incorporación lo arregla. Por eso conviene cuidar tanto la definición del puesto (te lo contamos en nuestra guía para contratar programadores para una startup) como la validación técnica de cada candidato. Si tu equipo no tiene tiempo o perfil técnico para validar, una agencia especializada en selección IT puede ocuparse de esa parte y entregarte solo candidatos ya verificados.