Ganarse la credibilidad del equipo
Esta semana vamos con una pregunta que me ha llegado por twitter
¿Cómo nos ganamos la credibilidad cuando llegamos a un equipo?
Aunque voy a responder a la pregunta, creo que muchas veces nos dejamos llevar por nuestro background técnico y pensamos que lo que realmente un manager necesita para poder liderar un equipo es ser la mejor programadora. Tener todas las respuestas técnicas, aportar de manera inmediata en la parte técnica. Yo creo que es más importante ganarnos su confianza. Y eso es much más accionable y lo que es más importante es mucho más útil para el equipo porque para que confíen en ti lo que tienes que hacer es ayudarles a mover las cosas, a facilitarles el trabajo, a resolver problemas, cuellos de botella, etc. Piensa que la credibilidad técnica normalmente no es algo que adquieres nada más llegar por varios factores:
Puede que vengas de background diferente (frontend vs backend).
Puede que incluso en el mismo background, los staks hayan sido muy diferentes.
Con toda probabilidad la forma de hacer las cosas serán diferentes.
Te falta el conocimiento del producto.
Te falta el contexto de las decisiones que se han tomado.
Sin embargo, como decía ayudar al equipo es algo que podemos hacer casi nada más llegar. ¿Cómo?. Identificando como eliminar dolores, preocupaciones y/o problemas que tienen.
Observa las dinámicas del equipo. ¿Por ejemplo, son las reuniones efectivas?. ¿Es el equipo efectivo?
Entiende el producto del equipo, la visión, el roadmap.
En el primer one on one con cada miembro del equipo, empieza a crear una buena relación de confianza. Y haz preguntas que te permitan empezar a entender los problemas que tienen.
¿Qué te está bloqueando para alcanzar tus goals?
¿Qué no está funcionando ahora mismo para ti?
¿Qué cambiarías en el equipo? ¿En la empresa?
¿Qué es lo que más te gusta del equipo, de la empresa?
¿Qué esperas de mí (tu manager)?
Te sorprenderá cuantos patrones se ve aquí, como la mayoría apunta a los mismos problemas.Habla con los stakeholders del equipo para entender todo el contexto. ¿Cómo nos ven otros?.
Entiende bien las cosas antes de proponer cambiar nada.
Una vez que has hecho estas cosas empezarás a ver posibles mejoras, puede ser ayudarles a priorizar mejor, a terminar en lugar de empezar cosas, pueden ser cambios en la metodolodía como hacer de manera más efectiva los dailies, pueden ser problemas en el entorno de desarrollo, hay mil cosas.
Busca quickwins, cosas que pueden parecer problemas simples, los detalles por pequeños que sean, generan confianza. Dan un mensaje claro, está aquí para ayudarnos. Especialmente si identificas problemas con el otro manager, como que no estaba para ellos o que no establecía las expectativas claramente o que había problemas de comunicación, de transparencia, etc pon mucho énfasis en arreglar estas cosas, por ejemplo en comunicar claramente, que tengan la información necesaria, etc.
No confundir esto con no necesitar ser técnico para ser manager, yo creo que es importante tener un background técnico sólido para entender los problemas que tiene el equipo, para participar en discusiones, para ayudar a crecer a la gente, etc. De hecho para mí lo ideal es que un IC no pase a manager hasta que haya llegado a senior y haya pasado algunos años programando. Lo que es clave es entender que no tenemos que ser los mejores programadores, ingenieros, que no tenemos que ser los expertos en la materia.
¿Pero si tenemos que ayudar a crecer a ingenieros como lo hacemos sin ser los expertos?
Pues porque muchas de las cosas en las que les tendrás que ayudar a crecer son horizontales independientemente de la tecnología. Y si hay algo específico en lo que si necesiten ayuda y te falten conocimientos, tu rol es ayudarles a encontrar a alguien dentro de la organización que les pueda hacer de mentor, y sino hay nadie, pues ayudarles a encontrar cursos, libros, lo que sea.
Además también debemos ir adquiriendo suficiente conocimiento del equipo y de su stack para poder hacer de manera efectiva lo que he mencionado antes, aquí va algún truco:
Si en el onboarding no te las han puesto, pon tu reuniones con miembros del equipo y de la empresa para entender el stack, la arquitectura, etc.
Céntrate en entender el stack, los servicios que tenéis, la arquitectura a alto nivel.
No intentes ponerte a comprender cada detalle de lo que hay. No lo necesitas inicialmente, eso llegará con el tiempo. Si te centras en entenderlo de manera inmediata, ¿sabes lo que pasará?. Pues que no estarás haciendo lo que he mencionado anteriormente y no estarás ayudando al equipo.No intentes ocultar que no conoces algo. Es normal, especialmente al entrar en el equipo. Pregunta sin miedo. Si crees que estás cortando las reuniones o entorpeciéndolas, apunta todo y resuélvelo después, con sesiones específicas.
Entiende que equipo tienes, quienes son los más fuertes en cada área (sea produto o técnica) y tira de ellos, delega.
Si aún así ves que tienes dificultades para seguir las conversaciones del equipo, en algún momento tendrás que dedicar algo de tiempo a formarte al menos en lo básico. Por ejemplo, en Gocardless uno de mis equipos programaba en React. De lo cual no tenía ni idea, así que me hice un curso para poder entender de que hablaban, para poder traducir ese lenguaje a problemas que nos encontramos en ingeniería y poder aportar.
Además de todo lo mencionado he visto otros enfoques que también han funcionado pero con matices:
Para demostrar la credebilidad técnica de un manager o lead que llega nuevo, he visto como en algunos sitios hacen una charla donde las persona cuenta su backgrond, haciendo mucho énfasis en proyectos complejos y el que tuvo.
Esto funciona sí el perfil es así, es decir, si la persona tiene mucho que mostrar o es impactante. Aún así, la cofianza te la tienes que ganar igualmente.Empezar en el equipo como uno más y luego pasar a manager.
Esto funciona bien si primero dejamos claras las expectativas a todo el mundo y el manager conoce bastante bien el stack del equipo.
Que he visto más de una vez como ésta es la idea, pero en realidad eres uno más pero también eres manager….. y claro, algo tienes que dejar de hacer.