5 min read
Primer día. La persona nueva tiene sus credenciales… a medias.
Nadie le explicó bien qué hace el equipo más allá del título del puesto. Le asignan una tarea “fácil para empezar” que en realidad requiere entender seis servicios distintos.
A la hora de almuerzo, come sola porque nadie pensó en organizar algo. Para el viernes, ya está dudando si aceptó el trabajo correcto.
O si el puesto es 100% remoto, nadie se preocupa por consultarle si tiene dudas: generales, horarios, permisos, etc.
Este escenario se repite con una frecuencia sorprendente, y no porque a nadie le importe — simplemente porque el onboarding rara vez se diseña con la misma intención que ponemos en, por ejemplo, un roadmap técnico.
Y sin embargo, las primeras semanas de alguien nuevo definen buena parte de si esa persona va a ser productiva rápido, o si se va a ir en seis meses.
Por qué las primeras semanas importan tanto
Las primeras impresiones son desproporcionadamente influyentes.
Si las primeras semanas se sienten caóticas, la persona nueva empieza a dudar — no de su capacidad técnica, sino de si el equipo tiene los procesos en orden.
Y esa duda, una vez sembrada, es difícil de revertir después.
Por el contrario, un onboarding bien estructurado logra algo que parece pequeño pero no lo es: que la primera semana de la persona nueva se sienta a la vez desafiante y manejable, no abrumadora ni aburrida.
Antes del primer día
El onboarding empieza antes de que la persona llegue. Preparar el terreno con anticipación evita que el primer día se consuma en trámites:
- Accesos y credenciales listos, no “en trámite”.
- Un equipo funcional, configurado, sin que la persona tenga que instalar el entorno completo desde cero sola. O por lo menos una guía del paso a paso de configuración.
- Un plan escrito de las primeras dos semanas, compartido de antemano, para que sepa qué esperar.
- Un buddy (compañero designado) asignado, alguien específico a quien preguntarle cualquier cosa sin sentir que interrumpe a todo el equipo.
La primera semana: contexto antes que código
El error más común es lanzar a la persona nueva directo a resolver tickets el primer día.
Se siente productivo para el equipo, pero deja a la persona resolviendo problemas sin entender el panorama completo — como pedirle a alguien que arregle una pieza de un motor sin haber visto el auto completo.
Mejor secuencia:
- Contexto de negocio: qué hace la empresa, quiénes son los usuarios, por qué existe el producto.
- Contexto de arquitectura: cómo están organizados los servicios, dónde vive cada cosa, qué documentación existe (los ADRs, si los tenés, son oro acá).
- Primera tarea real, pero acotada: algo con alcance claro, que toque el sistema real pero con bajo riesgo — un bug menor, no un feature crítico.
El rol del buddy
Asignar un buddy — alguien del equipo, no necesariamente el líder — que responda preguntas del día a día sin fricción cambia por completo la experiencia.
La persona nueva tiene alguien a quien preguntar “¿esto es tonto preguntarlo?” sin la carga de interrumpir a quien la está evaluando formalmente.
El buddy no reemplaza al líder — complementa: mientras el líder da dirección y feedback, el buddy da compañía práctica del día a día.
Guía práctica para las primeras cuatro semanas
Semana 1: contexto de negocio, arquitectura general, configuración del entorno, primer PR pequeño (aunque sea documentación o un fix trivial) para que experimente el flujo completo de principio a fin.
Semana 2: primera tarea real con acompañamiento cercano. 1:1 dedicado a preguntar cómo se siente, qué le costó, qué le faltó explicar.
Semana 3-4: tareas con mayor autonomía, participación activa en ceremonias del equipo (planning, retro), primera contribución visible para el resto del equipo.
Fin del primer mes: conversación explícita de check-in — no evaluación de desempeño, sino “¿cómo te sentiste este mes? ¿qué necesitás que ajustemos?”.
Señales de que el onboarding no está funcionando
- La persona hace muy pocas preguntas — a veces significa que no se siente cómoda preguntando, no que entiende todo.
- Pasa varios días sin hacer ningún commit ni contribución visible.
- En el 1:1, responde con monosílabos a “¿cómo va todo?”.
- El equipo no sabe bien en qué está trabajando la persona nueva.
Conclusión
Un buen onboarding no es una lista de tareas administrativas — es una inversión directa en qué tan rápido esa persona empieza a aportar valor real, y en si decide quedarse el tiempo suficiente para que esa inversión rinda frutos.
Las primeras semanas cuestan tiempo del equipo que ya está ocupado, sí. Pero comparado con el costo de una renuncia temprana o de meses de productividad perdida por falta de contexto, es de las inversiones más rentables que un equipo puede hacer.
Recordá suscribirte aquí para recibir los próximos posts directamente en tu correo.
Referencias:
The Manager’s Path — Camille Fournier
An Elegant Puzzle: Systems of Engineering Management — Will Larson