Por qué construí un motor genérico en vez de otro panel más
Un equipo de 7 personas, un panel de edición nuevo por cada cliente, y la decisión de parar a construir uno solo que los resolviera todos.

¿Cómo sabes si estás liderando bien a un equipo? Cumplir la meta es la parte obvia, la que nadie discute. Hace un tiempo empecé a medir algo más: cuánto crece la gente que lidero mientras trabajamos juntos para lograrlo, incluso hasta el punto de superarme a mí.
Hoy soy líder técnico de un equipo, después de un tiempo trabajando ahí como ingeniero senior. En el camino hacia ese rol, una asesora que me ayudó a desarrollar mi liderazgo me dijo algo que no se me olvida: casi nadie logra combinar buen criterio técnico y, al mismo tiempo, entender de verdad a su equipo. Y lo segundo no se aprende simplemente leyendo un manual. Fue la primera vez que vi el liderazgo como una habilidad que se aprende y se practica, no como algo que viene incluido si eres bueno programando.
Desde entonces cambié cómo hago 3 cosas: mis reuniones individuales, cómo delego, y cómo reviso el código de mi equipo.
Lo que me llevé
Con cada persona de mi equipo armo un plan de desarrollo con áreas concretas y medibles, no una intención vaga de "mejorar". Puede ser algo tan práctico como comunicar mejor una decisión difícil frente al equipo, o algo más técnico como profundizar en el diseño de un sistema completo. Lo que importa es que se pueda medir, no que se sienta nomás.
Antes de empezar cada reunión individual, digo lo mismo: este tiempo es tuyo, no vamos a revisar estatus aquí. El estatus tiene su propio espacio, en otra reunión, con todo el equipo. Si dejo que el estatus se cuele en la reunión individual, la persona termina reportándome tareas en vez de pensar en voz alta hacia dónde quiere crecer, y esa conversación no vuelve a pasar en ningún otro lado.
Porque decir qué hacer resuelve una tarea. Explicar por qué esa es la decisión correcta le da a la persona el mismo criterio para las próximas decisiones parecidas, sin que tenga que preguntarme de nuevo. Cuesta más tiempo al principio, pero es lo único que hace que delegar de verdad escale con el equipo.
Por ejemplo, decirle a alguien "usa esta librería" resuelve esa tarea puntual. Explicarle que la elegí porque el equipo ya la usa en otros 3 lugares, y no quiero una cuarta forma de resolver lo mismo, le da el mismo criterio para la próxima vez que tenga que elegir por su cuenta, sin que yo esté ahí para decírselo.
Cuando reviso el código de alguien y veo algo que podría mejorar, mi primera opción no es señalar que está mal. Es preguntar: ¿qué opinas si en vez de esto probamos de esta otra forma? ¿Te diste cuenta de que esto podría fallar si pasa tal caso? La idea es guiarla hacia que se dé cuenta sola, no decirle directamente dónde está el problema.
Con alguien más nuevo en el equipo, a veces sí soy más directo, pero incluso ahí evito decir "esto está mal". Prefiero algo como "esto no es una buena práctica, por estos motivos", y apenas puedo, vuelvo a las preguntas. Y si aun así la persona no llega sola a la respuesta, se la explico sin ningún drama. Nunca se trata de hacerla sentir mal por no haber llegado. Se trata de que la próxima vez tenga más con qué intentarlo por su cuenta.
No le doy la respuesta. La guío con preguntas hasta que la encuentra ella misma.
Vuelvo seguido a lo que me dijo esa asesora sobre combinar la técnica con entender a las personas. Con el tiempo la convertí en mi propia definición de éxito.
Para mí, liderar bien es simple de decir y difícil de hacer: que el equipo cumpla sus metas, y que las personas crezcan, incluso hasta el punto de superarme a mí.
Si lideras personas, cumplir la meta nunca deja de importar. Pero aprendí a medir algo más: qué tan capaz es mi equipo de lograr la siguiente meta sin que yo esté encima. Todavía estoy aprendiendo a hacerlo bien. Gracias por leer hasta acá. 🙂