Onboarding que funciona: cómo sumar devs nuevos al equipo

Tu nuevo dev no debería adivinar cómo arrancar.

Si alguien se suma al equipo y en la primera semana ya mandó su primer PR, entendió cómo trabajamos y sabe a quién preguntarle, el onboarding funciona. Si no, el problema no es la persona nueva: es el proceso.

La buena noticia es que el onboarding se diseña igual que el software: con intención, con etapas claras y con iteración. Acá te dejo las piezas que más marcan la diferencia para que una persona nueva sea productiva y se sienta parte desde la primera semana.

🚀 Antes del día 1: dejá todo listo

El día 1 empieza bastante antes del día 1. Si la persona tiene que esperar tres días por un acceso, perdemos impulso y confianza.

• Prepará los accesos: repos, herramientas, mensajería, entornos. Todo funcionando antes de que cruce la puerta.
• Dejá el entorno listo: máquina configurada o instrucciones claras de qué instalar.
• Asegurate de que el README de setup realmente funcione: probalo con alguien que no conozca el proyecto. Si tiene pasos que nadie ejecutó nunca, no es documentación, es ficción.
• Armá la agenda de la primera semana: a quién va a conocer, qué va a leer, qué va a hacer. Siempre hay imprevistos, pero el primero no debería ser “no tenía nada asignado”.

🤝 Asigná un buddy desde el minuto uno

Ninguna pregunta debería quedar sin respuesta porque la persona “no sabe a quién molestar”.

• Designá una persona concreta, no “el equipo”. Los equipos no responden preguntas: las personas sí.
• Bloqueale tiempo en la agenda al buddy: acompañar no es una actividad de rato libre.
• Dejale claro al equipo que el buddy es el punto de contacto para las preguntas chiquitas.
• Separá los roles: el buddy acompaña el día a día; la gestión y la evaluación quedan para quien lidera.

🔨 Un primer PR chico en la primera semana

Nada genera pertenencia como contribuir. Y nada aísla tanto como esperar semanas “para estar listo”.

• Elegí una tarea real pero acotada: un fix chico, una mejora clara, algo con impacto visible y bajo riesgo.
• Objetivo: primer PR enviado en los primeros cinco días. No importa que sea chico; importa que la persona recorra el ciclo completo de trabajo.
• Hacé un code review generoso: explicá el porqué, no solo el qué.

📚 Documentación viva, no un museo

• La persona nueva es el mejor detector de docs rotas: si algo no se entiende, es señal.
• Por cada “acá me trabé”, proponé un PR chico a la documentación.
• Hacelo parte del proceso: quien usa la doc la mejora. Así la documentación se mantiene fresca y la persona nueva deja huella desde el arranque.

🗺️ Plan de 30 días con expectativas claras

“Que aprenda mucho” no es un plan. Un plan dice qué se espera y cuándo.

• Semana 1: entorno andando, primer PR, conocer al equipo.
• Semanas 2 y 3: tareas reales con acompañamiento, entender el dominio.
• Semana 4: contribuciones propias y algo más grande que un PR chico.
• Escribí las expectativas y compartilas: el misterio es el peor de los gestores.

🔄 Check-ins frecuentes y feedback en ambos sentidos

• Cortos y seguidos ganan a largos y espaciados. Quince minutos por semana valen oro.
• Preguntá cosas concretas: ¿qué te trabó esta semana? ¿Qué te faltó?
• Dale feedback vos también: la persona nueva no tiene que adivinar cómo la estás viendo.
• Escuchá en la otra dirección: el propio onboarding se mejora con lo que te cuentan. Eso además le enseña a la persona nueva que acá se escucha.

⚠️ Los errores comunes que arruinan todo

• Tirar a la persona a leer un wiki desactualizado. Además de frustrante, manda un mensaje clarísimo: “acá nadie mantiene nada”.
• Dejarla sola “para que se rebusque”. Eso no es autonomía, es abandono con excusa.
• Sobrecargarla de reuniones. Si la primera semana es una maratón de calendario, ¿cuándo escribe código?
• Esperar el rendimiento de alguien con años de contexto. La productividad plena lleva tiempo; el objetivo de las primeras semanas es aprender rápido y con apoyo, no correr a full desde el día 1.

✅ Conclusión

Un gran onboarding no es un evento lindo de bienvenida: es un sistema. Accesos listos, un buddy presente, un primer PR temprano, docs vivas, un plan de 30 días y feedback que corre en los dos sentidos. Con todo eso en su lugar, la persona nueva no solo rinde antes: se queda, aporta y hace crecer al equipo. En CROBF creemos que la forma en que recibimos a alguien dice mucho de cómo trabajamos todos los días.

No esperes al próximo ingreso para mejorar tu proceso. Elegí hoy una sola cosa de esta lista —el README, el buddy, el plan de 30 días— y arreglala esta misma semana. Tu próximo dev (y todo tu equipo) te lo van a agradecer. 💪