First rule of leadership: everything is your fault. - Hopper, A Bug’s Life -

🎙️ Si eres más de escuchar que de leer, puede escuchar mi experiencia en el capítulo 13 del podcast {experiencias.de.un.programador();} de Carlos Blé

Hace casi 1 año que decidí cambiar mi rol como desarrollador y pasarme al mundo de la gestión.

Os quiero explicar mi experiencia personal.

Otros desarrolladores, en otros momentos, en otras circunstancias, pueden tener experiencias diferentes.

Tampoco tengo claro que hubiera pasado si hubiera sabido estas cosas antes de hacer el cambio de rol.

A lo mejor es necesario vivirlas y aprender por el camino para llegar a donde estoy hoy.

1. Los primeros días no vas a saber donde estas

A mi me grabaron en mis primeros dias como manager y lo publicaron en Twitter. 😱

https://twitter.com/darylginn/status/1181217370389524481

https://twitter.com/BrianPBosche/status/1275946311167049729

Yo tengo la sensación de que estuve haciendo eso en mis primeros días como manager.

Poco a poco irás encontrando tu sitio en los equipos y dónde puedes aportar más.

2. Hacer el cambio por las razones correctas

Si un desarrollador me dijera que quiere cambiar su carrera profesional y ejercer un rol de manager, lo primero que haría es preguntarle ¿cuáles son las razones para hacer ese cambio?

Es muy importante hacer el cambio por las razones correctas.

Por ejemplo, en España todavía hay muchas empresas en las que llegado a cierto nivel técnico tienes que hacer el cambio a la gestión para ganar más dinero. Suponiendo que ya ganas lo suficiente para tener tus necesidades cubiertas, si solo vas a hacer el cambio para ganar más dinero, mi consejo es que busques una empresa que te pague lo que crees que vales por hacer lo que realmente te gusta y te motiva.

Cambiar a un rol de gestión para ganar más dinero, sino te gusta, pronto se te olvidará el dinero y no irás a gusto a trabajar.

3. ¿Por qué es importante hacer el cambio por las razones correctas?

Pongo un ejemplo simplista. Ejercer un rol de manager no es como arreglar un problema en producción, en el que te metes, sufres un poco, lo arreglas y se acabó....

Ayudar a arreglar los problemas que tienes como manager son de largo recorrido y vas a tardar tiempo en arreglarlos.

Si no estás haciendo lo que te gusta cada día es muy frustrante.

Lo podías equiparar a trabajar cada día con la tecnología que más odies. Durante unos días, no hay problema, pero cuando ves que para aportar algo tardarás meses o años, se te hace un mundo.

4. ¿Voy a ganar más dinero como manager?

No tiene porqué ser así.

En tu empresa deberías cobrar por tu experiencia, pero sobretodo por el impacto y el valor que aportas.

En la compañía que trabajo actualmente, un desarrollador puede cobrar más que un manager.

Desarrollo y gestión son dos carreras profesionales paralelas y tú decides cual sigues.

5. Pero entonces si puedo ganar más dinero como desarrollador ¿para qué cambio de rol?

Cada uno puede tener sus razones.

Yo por ejemplo quería resolver problemas que como desarrollador eran muy difíciles de resolver pero como manager si son abordables:

• Mejorar el rendimiento de los equipos.
• Cambiar la cultura de desarrollo de la compañía.
• Cambiar las interacciones de los equipos con los stakeholders.
• Cambiar la velocidad a la que pasan la cosas.

6. El ciclo de recompensa

Uno de los mayores cambios que hay al pasar de desarrollar a gestionar es el ciclo de recompensa.

Cómo desarrolladores estamos acostumbrados a ciclos de recompensa muy cortos.

Tiras unas líneas de código y tienes algo visible, funcionando y en muchos casos ya lo usan tus clientes. ¡Buah, qué subidón! ¡Qué buenos somos!

Esto como manager no pasa, los ciclos de recompensa son muy largos, de meses o incluso años.

No cambias el rumbo de un equipo en unos días, no ayudas a otra persona a crecer profesionalmente en unas semanas.

Si no tienes claro esto, cada día será muy frustrante porque tendrás la sensación de no haber hecho nada.

Verás los resultados de tus acciones de hoy, en unas semanas o meses, te hayas equivocado o hayas acertado.

Pero cuando ves los resultado y ves a la gente crecer y convertirse en mejores técnicos o a equipos empezar a funcionar como una máquina engrasada, es muy gratificante.

7. Dejar de hacer las cosas y empezar a conseguir que las cosas pasen

Uno de los aspectos más difíciles cuando pasas de desarrollador a manager es dejar de hacer las cosas y empezar a conseguir que las cosas pasen sin hacerlas tú.

Al tener experiencia como desarrollador y trabajar con desarrolladores, más de una vez te verás en situaciones donde el enfoque técnico que plantea el equipo no es el que tú hubieras planteado.

Como manager solo deberías hacer las preguntas correctas para que el equipo vaya por el camino adecuado. Puedes marcar dónde queremos llegar, pero el camino en la dirección correcta lo tiene que andar el equipo.

Hay situaciones en las que llegarás a estar pensando "quita, que ya lo hago yo..." pero tú responsabilidad es hacer que esas personas crezcan y evolucionen y eso implica muchas veces que tendrás que aceptar soluciones con las que no estás de acuerdo, o soluciones en las que haya errores que no sean graves, ni hipotecan el futuro de la solución.
Son cosas necesarias para el aprendizaje.

También hay situaciones difíciles en las que tendrás que influenciar las decisiones del equipo para que hagan lo que es necesario, aunque no estén del todo de acuerdo en hacerlo.

8. Disagree & Commit

Tienes que conocer el principio de Disagree & Commit y vivir tranquilamente con ello. (https://en.wikipedia.org/wiki/Disagree_and_commit)

Como desarrollador ya deberías usarlo porque creo que es un principio muy importante para trabajar en equipo, pero como manager es imprescindible.

Cómo manager, una vez que el equipo toma una decisión, tienes que ir a muerte con ella, aunque en el momento de la discusión seas el más crítico o no estuvieras de acuerdo. Cómo manager eres una de las personas más influyentes del equipo y cuestionar la decisión de un equipo una vez tomada puede generar muchos conflictos.

Además puedes generar el precedente de que aquí lo importante eres tú y no el equipo.

9. Pasas de trabajar con la tecnología más puntera del mercado a trabajar con la más antigua, las personas.

Mucha gente me dice, ¡pero si yo trabajo con personas! ¡Trabajo en equipo cada día!

Pero que sepas resolver los problemas de tu código o que hagas pairing con tus compañeros, no tiene nada que ver con resolver los problemas de un equipo, hacer crecer a una persona o gestionar los conflictos entre personas.

Una vez que tomes la senda de la gestión, la tecnología queda relegada a un segundo plano.

10. No intentes arreglar todo el universo a la vez

El problema es que verás muchas cosas a mejorar y tu instinto de solucionologo-resolvedor de problemas saltará y lo querrá arreglar todo.

No quieras cambiar demasiadas cosas a la vez.

Mira, entiende los equipos, busca la causa raíz de los problemas que tienen, busca que tenemos que cambiar para tener más impacto y vete a por ello.

Los pequeños cambios cosméticos, rápidos pero que no arreglan el problema raíz, pueden servir para ponerte una medallita y acortar el ciclo de recompensa, pero el problema no lo has arreglado y volverá tarde o temprano por mucha pintura que hayas puesto.

11. Te darás cuenta de cosas que antes no veías

Por ejemplo, como desarrollador puedes percibir que un compañero no es bueno técnicamente, no hace el trabajo con el nivel de calidad que tú querrías, parece que vaya a la suya, etc..

Como manager muchas veces tienes que ayudar a esa persona porque de otra manera tendrá que dejar la empresa.

La enfocas, le das un propósito y un camino a recorrer y verás que muchas veces el problema no era la persona por sí sola, sino el momento, el proyecto, los compañeros....

Este tipo de cosas no sueles percibirlas como desarrollador y cuando consigues enderezarlas, son muy gratificantes.

12. Tus palabras son muy importantes porque tus palabras como manager serán usadas para bien o para mal.

Oirás varias veces la frase de "es que mi manager ha dicho", como si tu palabra fuera un mandamiento en piedra.

Ahora se me viene a la cabeza un ejemplo.

Tuvimos problemas graves con un sistema crítico en producción.

Una vez capeada la crisis y descubierto el problema, mis palabras al equipo fueron:

"El sistema puede volver a fallar, pero nunca puede fallar por estas mismas razones".

Esta frase la usa el equipo cuando tiene que justificar porque está haciendo cierta tarea para resolver un problema en lugar de otra....
"Es que mi manager dijo…."
Cómo desarrollador puedes ser más ambiguo en tus palabras, aunque no deberías, pero como manager tienes que ser claro y no puedes dar esperanzas a tus equipos de cosas que sabes que no van a pasar. Estarás destruyendo la confianza con tu equipo.
Tienes que ser sincero, si algo no va a poder ser, no des esperanzas.

Sé asertivo y realista pero empático.... Es muy fácil de decir pero muy difícil de hacer.
Por ejemplo, si sabes que tu empresa no será 100% remoto no des esperanzas a la gente con un ya veremos, nunca se sabe, a lo mejor....
Ser sincero puede hacer que haya gente que deje la empresa. No ser sincero hará que las personas pierdan la confianza en ti y en la empresa, será muy muy difícil recuperarla y posiblemente se irá más gente que si hubieras sido sincero.
Al final como manager tienes que ser coherente con tus actos y cumplir con tu palabra.

Y hasta aquí lo que he ido aprendiendo en mi camino en el cambio de rol.
Seguro que me dejo muchas cosas, así que añadidlas en los comentarios!

Talent wins games, but teamwork and intelligence wins championships. - Michael Jordan -