¿Debe programar un mánager?
Ésta es la pregunta del millón que sale en todos los talleres y diferentes conversaciones. La verdad es que la respuesta es… redoble de tambores 🥁🥁🥁🥁🥁 un decepcionante depende.
Depende del equipo en el que estás, de las dependencias que tengas, de los stakeholders que tengas, etc. Si tienes un equipo de 4 personas y sois autónomos e independientes, me sorprendería que no programaras. Si estás en un equipo donde para sacar un proyecto necesitas coordinarte con otros 4 equipos me sorprendería que lo hicieras. Si trabajas en una empresa muy burocrática y con muchos procesos, también te será difícil programar. Si tienes varios proyectos abiertos ídem…
La pregunta clave que debes hacerte es que dejas de hacer por programar y donde eres más necesario. ¿Estás dejando de atender a tu equipo? ¿No tienes tiempo para los 1:1s pero sí para programar? ¿No tienes tiempo para pensar de forma estratégica y siempre estás apagando fuegos?…
Tienes que plantearte que como mánager tu labor va más allá de programar, tu trabajo es multiplicar a la gente, hacerlos más autónomos, mejores, dar dirección, ponerlos en el camino para que tengan éxito. Si te encuentras en una situación en la que sin ti tu equipo no sale adelante, afróntalo como una oportunidad para desarrollar a tu gente.
A lo largo de mi carrera me he encontrado con muchos mánagers que no han entendido esto y eran un problema para el equipo más que una ayuda. Recuerdo un mánager al que al preguntarle por uno de sus proyectos, su respuesta fue que no sabía cómo estaba porque no podía estar en todo, estaba metido de lleno en otro proyecto del equipo, trabajando en la arquitectura e implementando, y ése era el problema. Tu responsabilidad como mánager son todos los proyectos de tu equipo, que salgan adelante todos y lo son todas las personas del equipo no solo las del proyecto donde estás al 100%. Ya lo he mencionado en otros artículos, Usain bolt no necesita que su entrenador corra más que él para ayudarle a ser mejor.
Otro ejemplo similar es el de un mánager que tenía. Era capaz de llevar 3 equipos, 2 directamente, además era una de las personas que más contribuían a un proyecto open source que teníamos, desde fuera parecía increíble pero la realidad era muy distinta. Cancelaba los 1:1s con frecuencia, sino los hacía rápido porque no tenía tiempo. Sus performance review eran poco útiles, 3 líneas mal puestas que no te ayudaban a crecer. ¿Qué estaba ocurriendo? Pues que estaba confundiendo su rol, la mejor forma de ayudar, de hacer su trabajo no es contribuir a ese proyecto sino maximizar, multiplicar a su equipo y sí lo que realmente le gusta o motiva es trabajar en ese proyecto open source perfecto, lo mismo debería seguir como IC en lugar de ir por la carrera de mánager.
Hay un momento clave para identificar cuando estamos siendo más un bloqueante que una ayuda para el equipo, yo lo llamo el momento de la vergüenza. Ocurre casi siempre en esos standups en los que os veis constantemente justificando porque la tarea que tenéis asignada está bloqueada porque ayer tuvisteis muchas reuniones o tuviste que hacer X.
Cuando cuento esto, la siguiente pregunta siempre es, ¿pero y cómo mantengo la credibilidad con el equipo? ¿cómo me mantengo técnico si no programo?.
La credibilidad la tienes por ayudar al equipo, por hacerles crecer, por ayudarles a tener éxito, por allanarles el camino, etc. Ya cubrí esto en detalle en esta edición de la newsletter.
Para seguir siendo técnico puedes participar en code reviews, puedes unirte a mob reviews, puedes coger esos bugs que seguro que tienes en el backlog que llevan allí meses y que nadie hará, esos bugs no importa si tardas 1 mes en terminarlos y eso te permite que le dediques una hora un día, tres otro, etc. Deberías involucrarte mucho en los diseños, en la arquitectura, no tanto proponiendo tú sino colaborando, revisando, añadiendo comentarios, etc
Es decir hay fórmulas para seguir entendiendo la parte técnica sin que tengas que dejar de hacer el trabajo de mánager.