De Desarrollador Senior a Gerente y Viceversa: El Viaje de Regresar a la Codificación

Imagina esto. Un día te unes a una reunión y te hacen la propuesta de pasar al puesto de líder gerente. Tienes una oportunidad, un ascenso, ta-da. Pero en un momento, una tormenta de preguntas comienza a surgir en tu mente. ¿Olvidaré cómo programar? ¿Mis habilidades se volverán obsoletas? ¿Seguiré siendo una persona técnica? ¿Es una buena decisión? ¿Y es posible volver a ser un especialista?

Lo estás pensando, y sí, lo estás haciendo. Pero con la suposición de que será un experimento y te dejarás una salida para volver.

Sí, ese soy yo. Y esa fue mi historia. Estaba en ese punto. Trabajé en Atlassian como ingeniero de software senior y hice la transición a un rol de líder de equipo. Lideré un equipo de seis personas. Trabajé en este rol durante 15 meses.

Y yo, mi nombre es Michał Michalczuk. Como puedes ver, ya no trabajo en Atlassian. Después de mi experimento, volví a un rol de desarrollador de software y trabajo como consultor en una pequeña agencia de consultoría con sede en Berlín. También soy un experto en varios formatos de JustJoin.IT. Puedes encontrarme también en sus redes sociales.

Pero volviendo al tema, pequeña advertencia, estoy compartiendo exclusivamente mi perspectiva. Y cuál fue mi contexto como gerente en Atlassian? El líder de equipo tenía que ser al menos un ingeniero de software senior, anteriormente el puesto P5. Era una gran organización. En el momento en que dejé la empresa, había 8,000 empleados. Teníamos una jerarquía multinivel y colaborábamos con muchos equipos en todo el mundo. La empresa tenía una gran cultura de ingeniería y un gran apoyo para los ingenieros. Cabe mencionar que cuando menciono gerente, me refiero al rol en el que tenemos subordinados directos. Entonces, ¿cuál era mi rol? Era un líder de equipo, pero ¿qué hay detrás del término líder de equipo? Bueno, el alcance de las tareas y responsabilidades puede variar de una empresa a otra. Así que echemos un vistazo a todo el espectro de roles técnicos e intentemos encontrar el mío. Tenemos tres áreas principales: la construcción de software, la estrategia y alineación, y la gestión de personas. Ese ciclo verde, que representa el rol con gestión de personas, son en realidad los roles de gestión.

Entonces, los roles en los que tienes personas que te reportan, por mal que suene. Y el gerente de liderazgo técnico y el gerente de ingeniería pueden ser un poco confusos. Permíteme intentar diferenciar entre los dos. El gerente de liderazgo técnico es responsable de la tecnología, por ejemplo, de sistemas específicos y ellos escriben el código ellos mismos. Es más probable que deleguen personas allí, que las distribuyan allí, pero aún escriben software. Luego, a la derecha, el gerente de ingeniería es responsable del desarrollo de personas y su trabajo en equipo. Además, en la parte superior puedes ver al ingeniero de personal, que también puede ser conocido como un desarrollador principal o un arquitecto. Y en el centro mismo, hay una zona de peligro, donde la mayoría de los CTO de las startups y los founders tienen muchos sombreros que usar al mismo tiempo, pero este no es el tema de la charla de hoy. Y como ya mencionamos, esos roles y esta división, debo agregar que el camino gerencial no es la única opción para obtener una promoción y ser ascendido después de ser un desarrollador senior, al menos en muchas empresas, gracias a Dios. Entonces podemos seguir el camino de ingeniería y convertirnos en ingenieros de personal o ingenieros principales. Podemos seguir el camino gerencial. Podemos movernos entre esos roles o incluso cambiar completamente de rumbo. Y aquí está el ejemplo de GitLab. Como puedes ver, esos caminos aquí, el gerencial, que está en la parte superior y el de ingeniería están en paralelo y casi hasta el último nivel, siguen yendo en paralelo. Pero volviendo al diagrama, mi rol era el de gerente de ingeniería. Tenía un equipo que me reportaba. Era responsable de organizar el trabajo y la estrategia del equipo, los objetivos del equipo y el desarrollo del equipo. También representaba técnicamente al equipo externamente, cuando era necesario, fuera del equipo, fuera de la empresa, de vez en cuando. Y tomé algunas decisiones técnicas de alto nivel con el apoyo de mi equipo, basadas principalmente en sus recomendaciones. Lo que ya no hacía era escribir el código yo mismo. Pero no me dejaron solo. Quiero decir, tanto en liderar al equipo como en el proyecto, lo llevábamos como un trío. Así que yo, como gerente, el gerente de producto, es decir, la persona encargada del producto, más el/la UX, es decir, el/la diseñador/a. Y mi equipo también formaba parte de la organización más grande, así que tampoco estaba solo allí. Y volviendo a los roles en sí, ¿qué roles cubren qué? Cuanto más pequeña es la empresa, más responsabilidades se concentran en un solo rol, incluso en una sola persona. Yo trabajé en una empresa más grande, así que centrémonos en eso. Y yo era responsable de cómo, como equipo, podíamos lograr el objetivo y cuándo. Entonces, en pocas palabras, ya que había más responsabilidades. Por cierto, en la preparación de esta charla, hice una lista de temas que no iba a cubrir. ¿Y adivina qué? Accidentalmente hice una lista de temas con los que tuve que lidiar como gerente de ingeniería, que incluía comunicación, desarrollo de miembros del equipo, ser parte del proceso de contratación, utilizar las estrategias de gestión correctas, y así sucesivamente.

Perdón por todo eso, pero me pareció bastante divertido. Y hay un poco de eso, y puede ser un poco abrumador, especialmente al principio. Entonces, ¿cuál fue mi comienzo entonces? Bueno, comenzamos el equipo con dos personas, con quienes ya había trabajado. Luego, el equipo creció. Al mismo tiempo, estaba en el curso de mejora de habilidades, el Aprendiz de Gerente de Atlassian. Duró alrededor de tres meses, con un compromiso de aproximadamente cinco a seis horas por semana, y muchas recursos externos que tuvimos la oportunidad de explorar. Tuvimos sesiones con otros gerentes, sesiones con HR, sesiones de juego de roles y ejercicios. Fue realmente genial y un gran apoyo. Y para mí, fue un comienzo muy suave.

También, porque siempre puedes volver a ser un IC, por IC me refiero al rol de contribuyente individual. Si decides que, hey, esto no es para mí, ser gerente no es para mí, es una práctica común en la gran tecnología. Además, comencé a participar en una gran cantidad de nuevas reuniones y conversaciones en Slack. Pero en ese momento, nadie requería mucha contribución o aporte de mi parte. Era más como una forma de aprendizaje por osmosis. Y en mi opinión honesta, ese comienzo suave fue realmente útil. Sí, pero hay peros, por supuesto.

Como gerente, no encaja bien, no sientes que te representa, suena muy estúpido. Pero sí, ese fue el problema, al menos para mí. La reacción inicial a los cursos que vi o leí como parte del programa de mejora de habilidades fue como, esto es una tontería. Como, todo es super vago. Al final, fue un conocimiento muy concreto y útil. Pero como ingeniero, sonaba como tonterías, al menos inicialmente. Además, en ese momento, intenté escribir todo el code o intentar escribir algunas especificaciones técnicas. Pero ya no hay opción para hacer eso, cuando los temas se multiplican y el equipo está creciendo. Así que sí, solo tengo que dejarlo ir. Y comencé a preguntarme, ¿qué estoy entregando incluso? ¿Entrego algo siquiera? Y la sensación de entrega, la gratificación se retrasa mucho en este rol. Y eso fue difícil. Esa gratificación a largo plazo en días y semanas, que es el ciclo de retroalimentación para ti como ingeniero, se convierte en meses y años. De repente, tienes muchos temas pequeños con los que lidiar, que te distraen de esos temas grandes y complejos que son importantes. Tienes cambios de contexto constantes, mucho trabajo reactivo, lo cual es terrible.

Sientes que te estás alejando, técnicamente, a nivel de code. Y tienes que hacer eso fue lo peor. Tienes que dar un paso atrás y entregar al equipo los temas que te encantaría abordar como ingeniero. Así que, esos fueron realmente difíciles. Y el más importante, el más importante, es que después de cambiar de rol, el centro de gravedad se desplaza de ti como contribuyente individual y tu trabajo individual al equipo. Y el equipo se convierte en el centro de gravedad. Entonces, si el equipo es el centro de gravedad, ¿qué te brinda satisfacción como gerente? Bueno, el éxito del equipo, nuevos lanzamientos, innovaciones introducidas, publicación de entradas de blog, y así sucesivamente. Cuando ves que el equipo ve los objetivos y contribuye a ellos, cuando ves que la visibilidad y el papel del equipo en la organización crecen, cuando ves que las personas en el equipo crecen y se desarrollan, cuando puedes promoverlos, y cuando el equipo trabaja por sí mismo, y tiene influencia, y es independiente, porque entonces tienes tiempo para tu trabajo, que es desarrollar estrategias, diseñar cambios e innovaciones propias. Ten en cuenta que todo gira en torno al equipo, no a ti como gerente. Y hay una cosa, también hay un sorbo de agua. Y hay una cosa que te concierne, me sentí genial cuando finalmente lo entendí es que como gerente tienes un impacto mucho mayor en la organización que cuando eres un desarrollador, porque ahora trabajas como equipo y el equipo trabaja para lograr este objetivo y este impacto. Muy bien, lo estoy elogiando mucho, pero ¿por qué volví a trabajar como desarrollador? Bueno, trabajar como gerente fue divertido, lo digo en serio. Fue un gran momento, mi equipo estaba muy satisfecho, mis compañeros de trabajo, también mi gerencia, pero al mismo tiempo extrañaba el aspecto práctico, extrañaba construir cosas, diseñar cosas, simplemente extrañaba trabajar como ingeniero. Y recuerdo, recuerdo el momento en que me estaba preparando para uno de los programas matutinos con las noticias de frontend, que solíamos grabar en ese momento, y estaba leyendo el artículo de Ryan Carniato, el creador de Solid.js, sobre las inconsistencias de la gestión local del sitio en varios frameworks de JavaScript, y me impactó, oh dios mío, no trabajé con algo tan de bajo nivel durante un tiempo. Y de repente, de repente los detalles de los componentes de React se vuelven de bajo nivel para mí, no el código ensamblador, el código ensamblador, los detalles de los componentes de React.

Lo cual está bien y es de esperar para ti como gerente, porque no estás interesado en esos detalles hasta que, no sé, seas gerente del equipo de React, sino que estás más enfocado en los sistemas y el nivel de interacciones. Pero personalmente, fue el punto en el que supe que simplemente lo extrañaba, y que me encanta deep dive y trabajar con los detalles. Sí, y en ese momento solo lo quería de vuelta.

Entonces, ¿fue mi experimento un éxito? ¿Qué aprendí? Que no se trata solo de ti, sino del equipo, siempre. Aprendí a gestionar mejor el tiempo y las tareas. Que el esfuerzo supera los resultados, especialmente si estás evaluando el trabajo de otras personas. Que la retroalimentación, la seguridad y el sentido de objetivo son los fundamentos de un equipo saludable, como siempre, independientemente del rol que tengas en ese momento. Y que un gerente no es un contador, no es alguien que solo siente el eje. Y si eso es cómo funciona en tu organización, está perdiendo su objetivo. Y que aún no hay una única forma de volver al rol, incluso en la misma organización.

Pero conozco personas que regresaron del rol gerencial al rol de desarrollador dentro de la misma empresa. Es más probable que lo hagas en equipos diferentes, especialmente si tienes una empresa más grande, entonces es más fácil hacerlo. Y en general, ¿qué ha cambiado para mí después de volver a ser desarrollador? Sí, como ya sabes, he vuelto a cambiar de roles. También me mudé de una organización de 8,000 personas a una organización de 20 personas. Y de una organización con una jerarquía multinivel a una estructura plana, y de la empresa que tiene todos los productos, trabajaba en el ecosistema de Jira y Atlassian, a básicamente externalizar. Aquí todavía prefiero las empresas de productos. Pero al volver al desarrollo, después de un mes, me sentí muy cómodo programando y codificando nuevamente. Pero al regresar al rol de contribuyente individual y pasar a una empresa pequeña con una jerarquía plana, me llevó como cinco o seis meses antes de sentirme 100% cómodo. Y estoy juntando todo esto porque es difícil señalar cuál cambio tuvo el mayor impacto, y probablemente también fue una cuestión de la nueva organización, que tenía un estilo bastante detallado. No entraré en detalles. Estoy feliz de hablar de ello en línea o en el mostrador de café en la conferencia.

Entonces, al final, desde mi experiencia, aquí hay algunos tips para aquellos de ustedes que están comenzando como gerentes, o considerándolo, mis tres principales. Recuerden, no están solos. Hablen con otros gerentes. El segundo, tengan reuniones individuales regulares con su equipo y con su gerente, su supervisor. No dejen que las cosas se pierdan y estén abiertos a la retroalimentación, lo cual puede ser difícil. Y ya no se trata de ti. Se trata del equipo. Si están entregando y desempeñándose bien, estás haciendo el trabajo correcto. Y si aún estás indeciso, ¿vale la pena? Desde mi experiencia, sí.

Obtendrás nuevas habilidades, nuevas perspectivas y crecerás como empleado, como persona. Siempre puedes volver al rol de ingeniería, al menos después de 15 meses, como lo hice yo.

Por favor, califica este discurso y dame tu opinión. Nos alimentamos de la retroalimentación, así que me encantaría conocer tus opiniones sobre la charla y sobre el tema. Por favor, hazlo. Y muchas gracias por tu tiempo. No dudes en contactarme en línea o en el evento. También estoy aquí.

Además, debajo de este código QR, puedes encontrar mi presentación con comentarios y enlaces. Así que siéntete libre de echarle un vistazo y jugar con ella. Y gracias una vez más. Que tengas una excelente conferencia. Adiós.