6 min read
Un desarrollador junior de tu equipo está trabado con un bug hace dos horas. Se acerca a preguntarte.
Tenés dos caminos: abrir su editor, arreglarlo vos en cinco minutos, y seguir con lo tuyo.
O sentarte a su lado, hacer preguntas, y dejar que sea él quien llegue a la solución en veinte minutos.
El primer camino es más rápido hoy.
El segundo es mentoría real — y es el único de los dos que hace que la próxima vez el problema se resuelva en diez minutos en lugar de dos horas.
La diferencia entre ayudar y mentorear
Ayudar resuelve el problema de hoy.
Mentorear construye la capacidad de resolver el problema de mañana.
Son valiosos los dos, pero se confunden con facilidad — y cuando un líder o alguien senior siempre elige “ayudar” (resolver directamente) porque es más eficiente en el momento, termina, sin darse cuenta, entrenando a su equipo para depender de él en lugar de crecer independiente.
La señal de alerta más clara: si la misma persona te trae el mismo tipo de problema una y otra vez, y vos lo resolvés cada vez, no estás mentoreando — estás siendo un cuello de botella con buenas intenciones.
El método socrático aplicado a código
En lugar de dar la respuesta, hacé las preguntas que llevan a la respuesta:
- “¿Qué esperabas que pasara acá, y qué pasó en realidad?”
- “¿Qué información tenés disponible para investigar esto? ¿Ya la revisaste?”
- “Si tuvieras que apostar, ¿dónde creés que está el problema?”
- “¿Qué probaste hasta ahora? ¿Qué te dijo cada intento?”
Estas preguntas hacen dos cosas a la vez: guían hacia la solución sin regalarla, y — más importante a largo plazo — le enseñan a la persona cómo pensar el próximo problema, no solo cuál es la respuesta de este.
Bonus Tip
El método del 1-3-1:
- 1 problema claramente definido: El 90% de las ocasiones, no se tiene claro cuál es el problema o qué está fallando. Una vez definido el problema claramente, la solución es más fácil de encontrar.
- 3 posibles alternativas: Es importante que la persona se vea forzada a pensar en una solución. Pero si le solicitamos 3 alternativas, se ve obligada a tomar en cuenta escenarios adicionales y tratar de encontrar diferentes puntos de vista. Esto es clave ya que no hay una única solución para un mismo problema.
- 1 recomendación: Si dependiera de esa persona, ¿cuál de las 3 alternativas escogería? En el 90% de los casos, esa recomendación es lo que usualmente soluciona el problema.
Cuándo SÍ dar la respuesta directamente
El método socrático no es dogma. Hay momentos donde intervenir directamente es lo correcto:
- Hay presión real de tiempo: producción está caída, no es el momento de una lección guiada.
- Es información, no razonamiento: si la persona no sabe que existe un comando o una herramienta específica, decírselo directamente ahorra tiempo sin quitarle aprendizaje real — no hay descubrimiento posible en “no sabías que esto existía”.
- La frustración ya escaló demasiado: después de mucho tiempo trabado, seguir insistiendo con preguntas puede sentirse como estar siendo evasivo en lugar de estar enseñando. A veces lo más generoso es resolver, explicar el razonamiento después, y guardar el método socrático para la próxima.
Ajustá el nivel de andamiaje según la persona
El concepto de scaffolding (andamiaje) de la educación aplica perfecto acá: das más estructura cuando alguien está empezando, y la vas retirando a medida que gana independencia.
- Alguien muy junior: acompañalo de cerca, explicá el razonamiento paso a paso, verificá el resultado juntos.
- Alguien con experiencia intermedia: dale el problema completo, revisá el enfoque antes de que empiece a codear, dejalo resolver solo.
- Alguien senior en un área nueva para ella: dale contexto y recursos, pero confiá en su criterio para el resto. Tratarla como junior en un área donde ya tiene experiencia general es, paradójicamente, desmotivador.
El feedback como parte de la mentoría
Ya hablamos en detalle de cómo dar feedback técnico en code reviews sin destruir la motivación — esas mismas técnicas aplican directamente a la mentoría, con un matiz adicional: en una relación de mentoría, el feedback también debe incluir reconocimiento explícito del progreso.
“Hace dos meses esto te hubiera tomado el doble de tiempo” es un tipo de feedback que casi nunca damos, y que tiene un impacto enorme en la confianza de la persona que está creciendo.
Guía práctica para estructurar la mentoría
1. Definí objetivos concretos, no solo “ayudarlo a crecer”: “que pueda diseñar un endpoint REST completo sin supervisión en dos meses” es medible. “Que crezca” no lo es.
2. Reservá tiempo dedicado: la mentoría que solo ocurre “cuando hay tiempo libre” casi nunca ocurre. Un espacio fijo, aunque sea de 30 minutos cada dos semanas, sostiene la relación mejor que la buena intención sin agenda.
3. Dejá que se equivoque en cosas de bajo riesgo: el aprendizaje real pasa por cometer errores y corregirlos. Elegí tareas donde el costo de un error es bajo, y dejá que el error ocurra ahí, en lugar de prevenirlo todo.
4. Compartí tus propios errores pasados: contar “yo cometí exactamente este error en mi segundo año” normaliza el proceso de aprendizaje y reduce la vergüenza de estar trabado.
Conclusión
La mentoría técnica genuina cuesta más tiempo hoy y ahorra mucho más tiempo mañana — no solo el tuyo, sino el de toda la organización, porque cada persona que crece de verdad deja de depender de vos para lo mismo una y otra vez.
Es una de las formas más silenciosas de multiplicar tu impacto como ingeniero senior: no por el código que escribís, sino por la capacidad que construís en las personas a tu alrededor.
Recordá suscribirte aquí para recibir los próximos posts directamente en tu correo.
Referencias:
The Coaching Habit — Michael Bungay Stanier
Talking with Tech Leads — Patrick Kua