Típicos problemas al pasar de IC a mánager.
Esta semana vamos a hablar de algo que sale siempre en los cursos de Engineering manager.
¿Qué consejo darías a una persona que va a transicionar de individual contributor (IC) a Engineering Manager?
Y es una pregunta comprensible porque la mayoría de mánagers acaban siendo mánager simplemente porque había una necesidad en la empresa y se les ha pedido dar el paso. De hecho para rematar la jugada, en demasiadas ocasiones se le pide a la mejor programadoro/a por ser los mejores y no por sus habilidades como mánagers o porque tengan inquietud.
Y una vez que dan el paso, no reciben ninguna formación e incluso en algunos casos ni siquiera tienen un modelo en el que fijarse. Así que voy a orientar esta newsletter a los dolores más típicos que suelen tener los mánager cuando empiezan y como evitarlos a tener cuenta.
No cometas el error de pensar que porque has pasado a mánager tienes que saber como hacer el trabajo. La mayor parte de managers hemos pasado por ese camino obscuro en el que no sabes que estás haciendo. Si tu empresa no tiene un grupo de mánagers con los que tengas reuniones semanales, búscate un mentor o varios. Alguien a quien puedas preguntar dudas, por ejemplo como lidiarías con una situación complicada, imagina una conversación en la que tengas que dar feedback.
Establece claramente cuales son las expectativas que tienen sobre ti. Como he mencionado anteriormente es muy normal que pases a mánager sin información y no solo es que tú creas que debes saber como hacer el trabajo, es demasiado normal que tu mánager también lo crea. Que espere que sepas hacer el trabajo por arte de magia. Incluso en las empresas en las que existe una guía de carrera es a menudo demasiado ambigua y no será fácil extrapolar como se traduce eso en el día a día.
Perder el control sobre tu tiempo.
¿Habéis tenido esa sensación de ir de reunión en reunión y no tener tiempo para hacer ninguna de las otras cosas que se supone que tienes que hacer?
¿Os encontráis que con el tiempo que se supone que teníais para hacer algo siempre os acaban llegando invitaciones para reuniones?.
Esto es bastante normal, la cantidad de reuniones varía en función del equipo. A más stakeholders, más gente en el equipo pues más tienes. Pero es muy común que durante los primeros meses nos veamos ahogados con reuniones.
Algo que también se sufre mucho es que con el nivel de interrupciones y cambios de contexto, el tiempo de foco se reducirá drásticamente. ¿Recuerdas esas largas horas de estar persiguiendo un bug…? Olvídate… seguro que tienes una reunión en medio.
Lo más importante es que empieces por entender cual es tu tiempo de foco, cuales son tus horas más productivas y esas las intentes proteger lo máximo posible. ¿Cómo? Pues aquí van algunos trucos:Se estricto con las invitaciones. Establece desde el primer día que las reuniones tienen que tener una agenda clara, donde veas porque eres necesario.
Bloquea slots en el calendario en tus horas más productivas. Hay varias normas no escritas en la industria para comunicar esto. Puedes ponerte una reunión contigo mismo cuyo título sea DNS (Do Not Schedule), Blocked, Focus….
Sin embargo, verás que muchas veces, la gente aún así te pondrá reuniones en esas horas. El truco final es poner en el calendario que durante esas horas estás fuera de la oficina, si usas Google Calendar con tan solo poner OOO ya rechaza de manera automática todas las reuniones. ¿Por qué esto es el truco definitivo?. Porque pone la carga de demostrar que necesitas asistir en quien invita. Es decir, cuando te ponen una reunión normalmente tú eres quien tiene que rechazarla, incluso ir y explicar porque no vas a asistir. Pero cuando pones OOO, al rechazarse la reunión de manera automática es la persona quien tiene que ir a ti a explicarte porque tienes que asistir.
Relación con tus compañeros.
Una vez que pasas a mánager, especialmente si transicionas desde el propio equipo tienes que darte cuenta de que la forma de relacionarte en el trabajo con tus compañeros de equipo ha cambiado, te guste o no. Muchas cosas que antes dabas por validas o en las que no te inmiscuías, ahora son tu responsabilidad.
Esos chistes que antes te hacían gracia ahora lo mismo te toca decir que no son apropiados para el trabajo. Decir a un amigo que no está haciendo lo que se espera de su rol o que tiene que mejorar no es nada fácil. Es muy normal que tengamos miedos a dañar la amistad.
Lo importante aquí es que seas claro desde el minuto uno, y en el primer 1:1 que tengas con cada miembro del equipo establezcas las expectativas. Éste es mi trabajo ahora y si no te doy feedback, no te digo donde y como mejorar, no estaré ayudando a progresar.
Esto es más complicado de lo que parece, a mí me costó mucho darme cuenta la primera vez que pasé de IC a mánager del mismo equipo.Ciclo de recompensas.
Esta es una de esas cosas que normalmente se pasan por alto, y de las que sueles darte cuenta cuando después de estar tus primeros meses como mánager cuestionándote todo el rato. “Hoy no he hecho nada!”, ¿Dónde se va el tiempo?.
Cuando pasas de contribuidor individual a mánager, pasas de tener éxitos y recompensas en el día a día a tenerlos en semanas, meses. Cuando resuelves un problema programando, notas ese subidón de manera inmediata, te vas a casa que no cabes en ti, pero cuando eres mánager lo normal es que tus problemas se resuelven en meses, tus problemas además ya no dependen de tu conocimiento técnico o del producto/dominio. Tus problemas normalmente son sobre personas, procesos, delivery, efectividad del equipo… A menudo tomarás decisiones para resolverlos que no tendrán sus frutos en meses, sean buenos o malos.El trabajo de mánager es algo más ingrato por eso, los resultados tardan en llegar y el reconocimiento también.
Un truco aquí es mantener una especie de log donde guardes los éxitos o las cosas que has conseguido en la última semana, hay muchas cosas que hacemos que consideramos normales o cotidianas que son wins. Puede ser desbloquear al equipo en un proyecto, tener un 1:1 en el que por fin entiendes las motivaciones de la persona o le motivas. Busca tus wins y anótalos. Por cierto, yo ya no lo hago, básicamente porque ya no tengo esta sensación.Apego al código.
Pasamos a ser mánagers pero queremos seguir haciendo lo que hacíamos antes. Queremos seguir contribuyendo en el día a día como uno más, pero se pasan los standups y lo que tenemos que decir es siempre parecido: “Ayer no avance mucho porque tuve que …..”. Hasta el punto de que bloqueamos tareas, de que a veces hasta nos da vergüenza. Cuando pasa esto es el momento de darse cuenta de que ayudamos más el equipo haciendo lo que se supone que es el rol del mánager y que nuestra labor es hacer de multiplicadores y no de blockers del equipo. Ayudarles a entregar valor.
¿Significa que no debes programar?. No, esto dependerá en gran medida de la cantidad de gente que tengas que gestionar en el equipo, además de la experiencia y lo autónomos que sean los miembros del equipo, o de las dependencias con otras áreas o equipos. A más stakeholders, más equipos con los que colaborar, menos tiempo para programar y más importante se hace que sepas salir del camino crítico del equipo dado que no tendrás la posibilidad de poner foco en realizar tareas de contínuo; te verás bloqueando al equipo constantemente dado que no tendrás tiempo de poner foco en la parte técnica. Lo que significa es que si para hacerlo tienes que renunciar a tus responsabilidades como mánager y/o bloqueas al equipo es momento de pensarselo. La pregunta que te ayudará a decidir esto es: ¿Qué dejo de hacer por programar?.Crecimiento profesional
Un error que se suele repetir con frecuencia, es ver a nuevos mánagers invirtiendo la mayor parte de su tiempo en crecer como ingenieros. Si trabajas como mánager, deberías crecer en ese rol, leer y formarte para ser mejor en ese trabajo. Los peores mánagers que he tenido siempre han tenido el mismo problema, eran demasiado técnicos y estaban tan preocupados por la parte técnica que rara vez se preocuparon por mí como persona, por mejorar mis habilidades no estrictamente relacionadas con el código, por ejemplo la comunicación. Los 1-1s con ellos, eran de forma constante preguntas sobre proyectos y la solución técnica que quería plantear.
Este tipo de perfil es muy valioso y existe un rol perfecto para ellos, Tech Lead. Esto no significa que una vez que pasas a ser mánager tengas que dejar de leer o crecer como ingeniero, no. Significa que tu prioridad debe ser hacer bien el rol que ahora desempeñas, máxime cuando has aceptado el cambio de forma voluntaria. Por otro lado, no sería justo para tu equipo ni para otras personas que de verdad quieran desempeñar ese rol.