A finales de 2019 decidí cambiar la dirección de mi carrera profesional y probar suerte como Engineering Manager.

Para este entonces, tenía un poco más de 10 años de experiencia desarrollando software como contribuidor individual.

Hoy me encuentro iniciando mi tercer año como Engineering Manager, y creo que es una buena oportunidad para reflexionar sobre estos primeros dos años. Te quiero compartir algunos aprendizajes que he adquirido, con la intención de que te sean de utilidad si es que decides seguir un camino similar al mío.

Pero antes…

¿Cómo me convertí en Engineering Manager?

Llegué al puesto de Engineering Manager con un set de ideas bastante claras sobre el tipo de líder que quería ser, así como de las estrategias particulares que emplearía para lograrlo. El tema de liderazgo y la psicología organizacional siempre me han llamado la atención, y continuamente estoy aprendiendo y educándome en estas áreas.

Durante mi tiempo como desarrollador, tuve la oportunidad de experimentar de primera mano los beneficios de tener líderes que genuinamente procuraban mi bienestar y mi crecimiento. También me tocó tener jefes, de los clásicos que nadie debería tener. Pude ver, gozar, y sufrir, gran parte del espectro de los tipos de líderes que existen.

También es importante compartir que adquirí mi experiencia profesional, principalmente en un ambiente de startups de Estados Unidos y Europa. Esto jugó un papel considerable en mi transición, pues mis primeros dos años como Engineering Manager fueron trabajando para empresas Mexicanas. A pesar de que soy mexicano, habiendo trabajado principalmente con personas extranjeras, sentí el cambio cultural.

Lo que aquí te voy a compartir no son verdades universales ni reglas. Tómalas como lo que son: interpretaciones de situaciones que viví a través de mis valores, experiencias propias y deseos personales.

Tus decisiones, por más pequeñas que sean, tienen grandes implicaciones

Como gerente de ingeniería, tus decisiones tienen la capacidad de influenciar desde la composición técnica de tu proyecto, hasta aspectos fundamentales del negocio. Pero, mayormente, tus decisiones afectan la carrera profesional de las personas a tu cargo.

Cualquier decisión que tomes, debes de factorizar el impacto a mediano y largo plazo que esta va a tener en la carrera de las personas con las que trabajas.

Sí, el producto es importante. Pero sin un equipo sano, todo pasa a segundo plano.

Tu trabajo como Engineering Manager es habilitar a tu equipo

Es demasiado sencillo llegar a un puesto de Engineering Manager pensando que lo que se espera de ti es que asignes tareas, y te asegures de que se cumplan a tiempo. Y hay personas que podrían argumentar que sí, ese es el trabajo. Yo creo que es un poco más complicado que eso.

El Engineering Manager, a diferencia de un Project Manager, se encarga de entender las necesidades y visión del negocio. Además, asimila las fortalezas, debilidades, y deseos de su equipo. El reto es alinear estos dos mundos de una manera coherente, sostenible y humana.

Parte de tus responsabilidades es procurar que los proyectos salgan a tiempo y en forma. Pero no asegurarte. ¿Qué vas a hacer, obligar a tu equipo a que trabaje horas extras? ¿Preguntarles “cómo vamos” cada 3 horas? ¿Intentar comprar su felicidad con pizzas y refresco? Todos hemos tenido (o por lo menos escuchado de) gerentes que usan esas tácticas. Personas para las cuales lo más importante es la fecha, el cliente y su reputación, no su equipo.

Reflexiona: ¿te gustaría (volver a) trabajar con una persona así?

Por eso digo que el Engineering Manager procura que las cosas salgan bien. Entiende las necesidades de su equipo (las personas), tiene conciencia de un balance adecuado entre vida y trabajo, y además reconoce y asimila las capacidades de cada uno de los miembros de su equipo. Después toma toda esta información, y crea estrategias, procesos y formas de trabajo que produzcan resultados fiables, en tiempo y forma. En este video exploro un poco más este tema.

Tienes que buscar un balance sostenible

La analogía que me gusta utilizar para este punto es la de las mascarillas de oxígeno en los aviones. Antes de despegar, el personal del avión hace las demostraciones de seguridad pertinentes, y comentan al respecto: “en caso de despresurización, antes de intentar ayudar a otras personas, asegúrese de tener la mascarilla bien puesta usted”.

El mismo consejo aplica para alguien en el rol de Engineering Manager.

Como alguien que desarrolla software (y más si vienes de la cultura Latinoamericana), probablemente te acostumbraste a glorificar el trabajo duro y pensar que estar ocupado es un símbolo de que estás haciendo algo importante. Cuando tienes ese bagaje cultural y de repente te encuentras en un rol de gerencia, naturalmente vas a buscar formas de mantenerte ocupado.

Pero como Engineering Manager, tienes que estar consciente de que tu rol es servir a tu equipo. Ayudarles a desbloquearse y a tomar mejores decisiones. Estar ahí cuando te necesiten. Y si no buscas un ritmo sostenible en tu rol, tu equipo lo va a resentir.

Tener un Engineering Manager quemado es como estar conectado a wifi que no tiene internet: sería menos frustrante no tenerlo en absoluto.

Lo que para ti pudiera parecer ayuda, para tu equipo se convierte en un perjuicio

No solamente importan las decisiones que tomas, sino cómo las tomas. El equipo que manejas aprende de tu estilo de resolución de problemas. Si no eres cuidadoso, precavido, diligente, transparente y disciplinado, le estás enseñando a tu equipo que está bien tomar decisiones “al ahí se va”.

Al inicio de mi carrera como Engineering Manager tenía lo anterior bien claro. A pesar de esto, no pude evitar caer (algunas veces) en la comodidad de tomar decisiones por mi cuenta y simplemente asignar tickets a mis equipos. No fue sino hasta después de un par de iteraciones, que me di cuenta de que la forma de trabajo que estaba impulsando no era sostenible. No solamente me estaba creando más trabajo, sino que además estaba afectando directamente el crecimiento de mis equipos.

Fue ahí cuando “hizo clic” la idea de que para ser un buen Engineering Manager, tenía que preocuparme más por habilitar a otras personas, que por hacer el trabajo yo mismo.

El feedback loop es muy largo

Tus decisiones deberían de estar basadas en el bienestar, sostenibilidad y productividad de tu equipo. Y los resultados de los cambios que implementes para fomentar una cultura de trabajo positiva tardan bastante ser aparentes.

Si tomas una decisión en función de prevenir el burnout de tu equipo, por ejemplo, el rango de tiempo para darte cuenta de si la estrategia está funcionando o no, podría ser de meses. No solo porque los cambios organizacionales son complejos y tardados, sino porque es muy difícil tomar una medición discreta del bienestar de una persona. Aunque tengas 1on1s recurrentes con cada miembro de tu equipo, las variaciones de estado de ánimo de una semana a otra pueden ser bastante grandes — y no siempre gracias a factores que tú puedas controlar.

Es por eso que como Engineering Manager tienes que enfocarte en las tendencias que ves en el equipo, no en datos discretos. Todos tenemos días malos, y si ves que alguien no la está pasando tan bien en tu equipo, no necesariamente tienes que hacer algo de manera inmediata (a menos que la situación lo amerite). Pero cuando ves que alguien ya lleva varias semanas pasándola mal, es momento de cambiar algo.

Cambiando el paradigma

Creo que hoy, más que nunca, es importante que humanicemos nuestro trabajo, y dejemos de glorificar las horas extras y el sacrificio del bienestar mental y emocional de las personas. Y considero que el Engineering Manager tiene un papel fundamental en esta transición.

Convertirme en Engineering Manager ha sido un proceso interesante. He aprendido mucho sobre mí y mis sesgos. Me he enfrentado a mi propio ego, y me ha ayudado a entender que el mundo en el que vivimos tiene muchos más matices de los que pensaba.

¿He tenido mis momentos difíciles? Sí. ¿He cometido errores? También.

Pero también he aprendido, y he crecido. Y si reflexiono un poco sobre estos primeros dos años en esta carrera, siendo honesto, considero que lo estoy disfrutando más de lo que disfruté mis primeros dos años como desarrollador.

Algunas reflexiones extras:

• No todas las empresas necesitan Engineering Managers. Hay algunas empresas que simplemente necesitan un Project Manager con nociones de ingeniería de software, pero no un Engineering Manager. Asegúrate de que sabes qué es lo que realmente necesitan.
• Ser Manager significa algo diferente para cada empresa. No te quedes simplemente con el título, indaga un poco más en cuáles son realmente las tareas y expectativas del puesto.
• Ser Manager no es para todos. Muchas personas creen que la progresión natural de una carrera en esta industria apunta hacia puestos de gerencia, pero no es así. Ser bueno escribiendo software desafortunadamente no te hace buen manager.
• Para ser Manager, necesitas renunciar a tu identidad como desarrollador. Ve este video para saber más.