Onboarding

En los últimos años he pasado por varias empresas, con lo que he vivido el onboarding en primera persona. Además los roles que he tenido en las distintas empresas me han hecho ser partícipe de su diseño, desde ser responsable técnico de una startup, a ser engineering manager en una scaleup como Gocardless y finalmente engineering manager en una de las empresas más grandes, Google. Esto me da una buena perspectiva de lo que es el proceso de onboarding, sobretodo de lo valioso e importante que es.

Lo primero de todo es que las empresas deben tener en cuenta que el onbarding es como la muerte y la vida, el día que naces ya empiezas a morir, el onboarding es el primer granito para que la gente se vaya.

Una cosa importante, como casi todo en tecnología, conviene tener claro el tamaño de tu empresa, una startup con 10 empleados no necesita un onboarding gigante ni super estructurado, no obstante las cosas que cuento aquí creo que muchas aplican a todas las empresas.

El objetivo del onboarding es ayudar a la gente a que esté integrada lo mejor y más rápido posible, asegurarte que la carrera de esa persona en la empresa empieza de la mejor forma posible.

En líneas generales esto es lo que yo considero que un proceso de onboarding tiene que tener.

• Debe explicar cómo funciona cada equipo en el que esa persona tenga alguna interacción, también debería haber sesiones explicando las cosas críticas o más importantes, por ejemplo, si es técnico, debería haber una reunión explicando la arquitectura, otra las releases, deploys, etc
• A ser posible estas cosas deberían estar documentadas y cada new joiner debería actualizar esa documentación cada vez que detecta que no está actualizada.
  Como todo en la vida hay tradeoffs, la documentación requiere mucha disciplina para mantenerla al día pero con ella ganas que no tengas que tener una reunión para cada cosa y además que la gente se olvide de contar algo.
• Establece claramente el tiempo de ramp up (vamos, de estar al 100%)  o mejor dicho deja claras las expectativas, por ejemplo: para tu puesto lo normal es que seas productivo en 3 meses.
• El onboarding debe tener checkpoints para asegurar que se está haciendo el progreso adecuado. Cuando tengas claro tu proceso, decide cuántos días/semanas require y pon checkpoints con la persona para ver como va y ver como ayudarla. Tener un sistema de buddies/amigos en los equipos ayuda mucho con esto, cada new joiner debería tener a alguien ayudándole, algo así como un mentor o guía. Alguien que la persona que entra sabe que es OK interrumpirle cuando lo necesite.
• Please, please, please asegurate de que el onboarding establece claramente los valores, la cultura. Hay muchas empresas que tienen talleres de unconscious bias, esto ayuda a que la diversidad sea más posible, a que la gente confíe más en la gente con la que trabaja, etc.
• Sé estricto con el proceso, por ejemplo si un lead ve que un newjoiner no está haciendo el proceso y se ha puesto directamente a programar, debería hablar con él y explicarle porqué es importante hacerlo. Por ejemplo, si no sigue el proceso con toda seguridad cometerá errores que se da por asumido que no deberían pasar, como crear un ticket de forma incorrecta, no seguir el workflow de la forma correcta (por ejemplo, pillar tareas de derecha a izquierda), etc.

Para cada cosa que quieres que pase debe haber una tarea en un checklist y un responsable, sino no pasará.

¿Cómo haría yo el onboarding en una empresa ahora mismo?

Lo primero de todo es analizar cuáles son las cosas básicas que un empleado tiene que saber y tiene que hacer. Analiza esto desde el punto de vista de recursos humanos y de equipo, es decir, por un lado están las cosas que necesitas para la empresa, por ejemplo, actualizar su información en la intranet del sistema para que puedan cobrar y por otro lo que necesita tener/hacer para trabajar en el equipo, un ejemplo de esto son los grupos de email/slack en los que tiene que estar.  Esto debe ser una especie de tarea ongoing, en algunas empresas es un grupo de trabajo formado por gente de RRHH y de otros departamentos/secciones (ingenieros, product managers, etc).

Con esa información creas varios checklist (por ejemplo en trello):

• Un checklist para la gente de recursos humanos o people. Con lo que tienen que hacer. Aquí va una pequeña lista:
  • Charla explicando los perks o beneficios. Cuáles son, cómo se pueden usar, etc.
  • Charla explicando la cultura de la empresa, los valores…. Importantísima sobre todo si la empresa está creciendo mucho. No me entendáis mal, la cultura se vive, es como se comporta la gente pero explicar las razones/motivaciones hace que la gente entre con el mindset adecuado y entienda ciertos comportamientos. Por ejemplo, en Gocardless uno de los valores es «start with why» y la gente lo usa constantemente, al entrar choca sino te han explicado why (pun intended :D)
  • Poner reuniones en el calendario con las personas/equipos que necesite conocer. Por ejemplo, una reunión con alguien de ingeniería para que le explique la arquitectura. Otra con un PM para explicar el producto, etc. Una charla muy importante y que se suele olvidar es explicar cómo funciona el desarrollo del producto. ¿Usáis OKRs? ¿Tenéis Roadmap divido en 4 quarters? ¿Cuál es el proceso para decidir qué hacer? ¿Cómo le afecta a él/ella?
  • Añadir a la persona en todos los sistemas que tenga la empresa (Intranet, slack, correo, etc).
  • Añadir una reunión con su manager el primer día para asegurarse de que es bien recibido/a. Más sobre esta reunión abajo.
  • Organizar comida el primer día con el equipo.
  • Poner ticket a IT (o a quien se encargue si es que no tenéis ese departamento) para que tenga el ordenador listo para empezar a trabajar, nada de que el primer día te toque instalar 20 cosas.
• Checklist para el Lead del equipo al que se une (este checklist debe ser mantenido por el equipo). Ejemplos:
  • Añadir a esa persona a las listas de correo del equipo.
  • A los grupos de slack.
  • Charla con el lead (o leads si hay varios) para explicar que hace el equipo, el objetivo del equipo, etc.
  • Charla/reunión o indicar donde está la documentación para saber cómo trabaja el equipo. Usáis SCRUM? Kanban? Jira? Trello? ¿Cuál es el flujo?
  • Explicar como es el proceso de desarrollo, ¿cómo es un deploy?.
    Una cosa que he visto en varias empresas y que funciona muy bien para entender el proceso, es que en la primera semana, incluso el primer día, la persona haga una tarea muy muy simple, como añadir tu nombre a una lista. La idea es que tenga un tutorial guiado en plan:
    • Clona el repo X. Si no conoces Git, lee primero esto [Link].
    • Añade tu nombre en la el archivo employees.py.
    • Añade un commit. Lee este documento para entender cómo generar un buen commit.
    • …….
  • El equipo/empresa debería tener una lista de recursos/tutoriales para que la persona pueda aprender a ser productiva. Por ejemplo, si usáis Java pues al menos un enlace a algún sitio que explique lo más básico. Crea un pequeño proceso para enseñar a esa persona progresivamente. Puede ser hacer pairing durante algunas semanas con alguien o poner una label a los bugs que son new joiner friendly, de forma que las personas que entran pueden empezar por eso. Cuidado con lo último, si usas ese modelo, imho deberías de tener a alguien ayudando a esa persona con esas tareas inicialmente.

Merece una mención especial la reunión con el manager, en la primera semana el manager debería explicar qué esperan de esa persona, cuál es su trabajo, como te van a evaluar, etc, no vale que el manager te pregunte a tí cosas del estilo a «en qué te puedo ayudar?» y nada más.
El manager tiene que dejar muy claras las expectativas. Explicar muy bien cómo va a ser su relación (cadencia de reuniones por ejemplo),  cómo funciona la empresa desde el punto de vista de progresión de carrera. ¿Cómo son las promociones? ¿Hay un framework de competencias o career path definido?, ¿Cómo funcionan las subidas de salario?, ¿Cuándo son las performance review?

No hay una fórmula mágica, vas a fallar, Itera, mejora y aprende con cada persona que entra.

Un mensaje a la gente que entra en una empresa, depende de como te tomes el onboarding puede ser un desastre o una oportunidad para empezar a tener impacto en la empresa y cambiar las cosas.