Cómo evitar la sobreformación y no morir en el intento
La primera vez que me asignaron como mentor técnico de un grupo de recién llegados, me hice la siguiente pregunta:
¿Cómo se crea una ruta de aprendizaje que transforme a un developer junior en alguien autónomo y valioso para el equipo?
Pero espera… teníamos las entregas encima, una base de código bastante compleja, y un equipo que apenas se estaba conociendo. El reto era claro: formar sin retrasar y enseñar sin microgestionar.
¿La verdad? Cometí bastantes errores. Pero también descubrí prácticas que hoy siguen siendo parte de mi forma de liderar.
El error de intentar enseñar TODO
Lo primero que hice fue crear un temario “completo”, algo así como fundamentos, git, patrones de diseño, arquitectura, testing, buenas prácticas, cloud… inserta aquí todos los temas posibles, porque estoy seguro que los consideré.
¿El problema? para mí todo era importante y eso estaba bloqueando el avance. Con el tiempo entendí que una buena formación no es un roadmap lineal escrito a piedra. Es más bien es una guía de supervivencia. Es decir, enfocarnos en lo esencial para aportar valor, sin dejar de aprender.
Así que comencé a cambiar el enfoque.
1. Primero lo real, luego lo ideal.
Dejamos a un lado la teoría y empezamos con problemas pequeños, pero reales. Reuní al equipo en una sala de juntas y comenzamos a tirar líneas de código juntos: codo a codo, aportando ideas, resolviendo features “básicas”.
La motivación subió cuando esas primeras líneas llegaron a producción. Ver algo tangible, real, propio, fue un punto de inflexión.
2. Definir habilidades base por etapas
En vez de decir “tienes que saber JavaScript", lo dividí en niveles concretos y medibles, por lo que siempre estaba buscando features que pudieran adaptarse a cada etapa:
- Nivel 1: Variables, tipos, funciones, manipular el DOM, escuchar eventos, formularios, entender cómo se ejecuta el código. Si eres un developer avanzado podrás darte cuenta que esto es el pan de cada día y en donde más errores se pueden cometer.
- Nivel 2: Uso de módulos, closures y algunos patrones. Con esto buscaba que comprendieran cómo separar la lógica de UI, consumir APIS y estructurar código por responsabilidad.
- Nivel 3: Testing, medir tiempos de respuesta, documentar código, nombres coherentes. En este nivel siempre se hizo pensando en como si otra persona (o uno mismo meses después) fuera a mantenerlo.
3. Feedback
Aprendí a dar feedback desde la madurez y empatía, cambie el “esta mal” por ¿Que crees que pasaría si…?. Eso generó más confianza y mejores conversaciones técnicas. Nadie estaba frente a un juez, sino frente a un compañero que quiere que mejores.
4. Aprendiendo de los errores.
- Dejé de asumir el “ya debería de saber esto” solo por el simple hecho de que lleva tiempo en el equipo ya que todos somos seres humanos y tenemos un ritmo de aprendizaje totalmente diferente.
- Hacer code reviews sin explicar por qué eso (si lo hubiera) podría causar problemas.
- Dejar solo tareas de bajo impacto a juniors. ¿Porqué? se estancan. Mejor darles retos con soporte. El crecimiento llega cuando hay responsabilidad real.
Alinear con el negocio no es opcional
No todo se trata de formar técnicamente, Cuando un developer entiende el producto y su objetivo aporta 10 veces más. Por eso siempre busco integrarlos en sesiones sobre el negocio, reuniones con otras áreas y charlas sobre el “por qué” de lo que hacemos.
Preguntas como ¿quién va a usar esto?, ¿qué problema resuelve?, ¿y si el usuario hace esto otro? cambian la forma en que escribimos código.
Conclusión
Formar talento no es un gasto, es una inversión. Requiere mucha intención, tiempo y paciencia, pero… también nos obliga como líderes o mentores a mejorar nuestras habilidades: empatía, forma de explicar y claridad técnica.
Porque al final del día, enseñar no es repetir lo que sabes…
