Tu primer cambio en producción antes del viernes
Cómo son los onboardings en Macro Securities
Cada persona que ingresa al equipo de ingeniería de Macro Securities tiene un objetivo claro: hacer su primer cambio en producción antes del viernes de su primera semana.
Por qué pusimos este objetivo
La decisión no fue arbitraria. El onboarding es la primera impresión que una persona tiene de cómo trabajamos. Y quería que esa impresión fuera clara desde el día uno.
Teníamos varios motivos para mejorar nuestro onboarding.
La primera era humana. Queríamos que las personas que ingresan sientan que son parte del equipo desde el primer momento. Que no pasen semanas siendo espectadores. Que contribuyan, que su código esté en producción, que vean el impacto de su trabajo rápido.
La segunda era cultural. Me encanta que el equipo completo sienta la responsabilidad de integrar a los nuevos miembros. Que el onboarding no sea un trámite de HR sino un objetivo compartido: lograr que la persona nueva sea productiva en cinco días.
La tercera era operativa. El problema de los permisos no se iba a resolver solo. Necesitábamos atacarlo de raíz, no caso por caso. Así que creamos nuevos perfiles de usuario para los desarrolladores de Macro Securities, diseñados para que los permisos necesarios estén disponibles desde el día uno. Simple, pero alguien tenía que hacerlo. Tenemos mecanismos armados para que el nuevo miembro ya tenga todas las herramientas necesarias en el primer día con nosotros.
Cómo funciona
El mecanismo es simple.
A cada persona que ingresa se le asigna un primer ticket. El criterio para elegirlo es uno solo: que pueda completarse en una semana. Puede ser un cambio menor, no importa el tamaño. Lo que importa es que la persona recorra todo el flujo de trabajo: hacer setup de su ambiente local, participar de las daily meetings, aprender lo suficiente del codebase como para tomar una tarea, desarrollar, testear, pasar por code review y mergear a main.
El ticket es casi una excusa. Lo que realmente estamos haciendo es que la persona viva el ciclo completo de desarrollo en cinco días.
Además, a cada persona nueva se le asigna un buddy: alguien del equipo que la acompaña durante esa primera semana. Que le responde preguntas, que la guía, que la ayuda a destrabar cualquier obstáculo. Esto último no lo definimos, pero fue surgiendo naturalmente. Y por supuesto, todo el equipo está disponible para dar soporte.
Esto solo es posible porque las bases están en su lugar. Nuestro pipeline de CI/CD es confiable, trabajamos con trunk-based development y short-lived feature branches, y los releases son semanales. Si cualquiera de esas cosas no funcionara, pedirle a alguien nuevo que haga un merge a main en su primera semana sería irresponsable, no ambicioso.
Lo que dice el equipo
“Remarco la buena predisposición del equipo, sobre todo del TL que me incluyó desde el inicio en decisiones sobre ambientes y temas propios del puesto. Si bien fue un PR chico, no tuve mayores problemas.”
— Nahuel Perez, Sr. Frontend Developer, ingresado hace 2 meses
“La verdad lo viví con un poco de ansiedad y bastante entusiasmo porque nunca había tenido la oportunidad de explicarles el negocio y el proyecto a nuevos devs desde el lugar que estoy hoy.”
— Agustina Torres, Sr. Backend Developer, presentó a los nuevos ingresos sobre el negocio y la tecnología que usamos
“Mi primera semana fue muy intensa. Sentí que hubo mucho foco y energía puesta en algo concreto: que yo empiece a aportar valor lo antes posible. Eso generó que todo el equipo esté muy predispuesto a ayudarme con los accesos, conexiones y herramientas necesarias. El primer día ya tuve una reunión de onboarding donde me explicaron el negocio, las herramientas y los lineamientos técnicos.”
— Ignacio Brezan, Ssr. Backend Developer, ingresado hace 1 mes
“Siempre acompañar a alguien nuevo genera una sinergia linda porque se aprende a la par. El nuevo integrante del equipo aprende del negocio, el stack tecnológico que usamos, las metodologías de trabajo […]. La mejor parte es que todo el equipo empieza a proponer mejoras en estos espacios y tenemos feedback constante.”
— Rodrigo Sanz, Ssr. Backend Developer, acompañó a uno de los nuevos ingresos
“[Mi primera semana fue] ¡Intensa pero genial! Estaba nerviosa por tocar código tan pronto, pero el equipo me dio todo el soporte […]. Es mucho más humano. En otros lados el onboarding suele ser ‘aprender sobre la marcha’ por pura necesidad o falta de proceso, lo cual suele ser frustrante. Acá, se notó una intención clara de integrarnos y un acompañamiento constante ante las dificultades desde el día uno.”
— Lucero Gonzalez, Ssr. Frontend Developer, ingresada hace 2 meses
Lo que dice de nuestra cultura
Un onboarding rápido no se logra con un buen documento de bienvenida. Se logra cuando todo lo demás está bien: los permisos resueltos, el pipeline confiable, los cambios chicos, el equipo comprometido con integrar al nuevo.
En cierto sentido, este objetivo es un test de salud de nuestra ingeniería. Si no pudiéramos cumplirlo, significaría que algo en nuestro proceso está roto.
Que lo cumplamos consistentemente me dice que vamos por muy buen camino.
Cierre
El onboarding es la primera promesa que le hacés a alguien que se suma a tu equipo. Y esa promesa define expectativas.
Si en tu primera semana pasás tres días esperando permisos y dos leyendo documentación desactualizada, el mensaje es: “acá las cosas son lentas y nadie se hizo cargo de preparar tu llegada.”
Si en tu primera semana ya tenés código en producción, el mensaje es otro: “acá confiamos en vos, las cosas funcionan, y vas a crecer.”
¿Cómo es el onboarding en tu equipo? Me encantaría saber cuánto tarda alguien nuevo en hacer su primer cambio productivo.