Primeros 30 días de onboarding en ingeniería

La mayoría de los programas de onboarding están diseñados para proteger a la empresa, no para acelerar al ingeniero.

Ese es el frame equivocado. La forma más rápida de proteger a la empresa es lograr que los nuevos ingenieros sean genuinamente productivos, no solo cumplidores.

Qué cuesta un mal onboarding

Una vez contraté a una ingeniera senior sólida que estuvo en la empresa 45 días antes de entregar algo significativo a producción. No fue su culpa. No teníamos onboarding estructurado. Las primeras dos semanas las pasó consiguiendo accesos, buscando documentación que no existía, y en reuniones que le daban contexto de empresa pero cero contexto de producto.

Para el día 45 estaba frustrada y yo estaba preocupado. Para el día 90 lo había resuelto por su cuenta y funcionaba bien. Pero son tres meses de salario completo por unas seis semanas de output real. Y ese costo vino completamente de nuestra falla, no de la suya.

Después de eso, construí una estructura de onboarding. Ha evolucionado con varias contrataciones pero la forma se ha mantenido igual.

Semana a semana

Semana 1: contexto, no código. No empujes a los nuevos a hacer shipping en la semana uno. Usa la semana para recorridos de arquitectura, leer decisiones pasadas, y entender por qué las cosas son como son. Le doy a cada nuevo integrante acceso al registro de decisiones desde el primer día, no para estudiarlo exhaustivamente, sino para que sepa que existe y pueda referenciarlo.

Semana 2: primer cambio en producción. Pequeño. Ridiculamente pequeño, idealmente. Un cambio de configuración, una corrección de copy, una mejora de mensaje de error. El objetivo no es el cambio en sí. Es aprender el pipeline de despliegue de extremo a extremo bajo baja presión. Todo equipo tiene quirks en cómo el código llega a producción. Mejor descubrirlos en un PR de una línea que en un feature.

Semana 3: ser dueño de algo acotado. Un ticket real, con un definition of done real, de extremo a extremo. Diseño, implementación, coordinación de QA, despliegue. Sin andamiaje excesivo, pero con una persona nombrada disponible para preguntas. Aquí es donde empiezas a aprender cómo el nuevo integrante piensa sobre los problemas.

Semana 4: presentar y proponer. El nuevo integrante presenta lo que aprendió al equipo, no como actuación, sino como forma de consolidar su propio entendimiento. Luego propone una mejora concreta: un hueco en la documentación, un proceso que se sintió lento, una herramienta que ayudaría. Aunque la propuesta nunca se implemente, el acto de hacerla dice mucho sobre cómo piensan.

Los innegociables

Tres cosas que tienen que existir o nada de esto funciona:

Un dueño de onboarding nombrado (no el manager, idealmente). Alguien en el equipo que sea responsable del primer mes del nuevo integrante. Ownership secundario significa que nadie lo prioriza.

Un backlog de inicio con tickets reales. No tareas de tutorial, no trabajo de tooling interno que nadie usa. Trabajo real del backlog de producto, acotado para ser alcanzable en días, no semanas.

Un registro de decisiones que cubra por qué el sistema está construido como está. No un wiki lleno de páginas que nadie lee, sino un log cronológico de decisiones importantes con el razonamiento adjunto. Este es el artefacto que responde “¿por qué esto funciona así?” sin requerir una interrupción a un ingeniero senior.

La medida

El onboarding es medible. Tiempo hasta el primer PR aprobado. Tiempo hasta la primera entrega autónoma. Si el ingeniero puede explicar el sistema a alguien más para el día 30.

Si esos números no se rastrean, estás volando a ciegas y pagándolo en tiempos de ramp lentos que has normalizado sin darte cuenta.