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 cada reunión individual digo lo mismo: este tiempo es tuyo. Los avances del proyecto los revisamos en otra reunión, con todo el equipo. Si dejo que las tareas ocupen este espacio, la persona termina reportándome pendientes en vez de pensar en voz alta hacia dónde quiere crecer. Esa conversación necesita su propio momento.
Porque una instrucción ayuda a terminar una tarea. Explicar el razonamiento ayuda a tomar la siguiente decisión parecida sin tener que preguntarme. Al principio toma más tiempo, pero he visto que vuelve al equipo menos dependiente de mí.
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 ayuda a evaluar lo mismo la próxima vez que tenga que elegir.
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. Si aun así necesita ayuda, se la explico. Busco que tenga más con qué intentarlo la próxima vez, sin hacerla sentir mal por preguntar.
Al revisar código, guío con preguntas para que la persona encuentre la respuesta. Si necesita más ayuda, se la explico.
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á. 🙂