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

Imagina esto. Un día te unes a la reunión y te proponen pasar a la posición de líder-gerente. Wow, qué ocasión, promotion, lejos, lejos, ta-da. Pero en un momento, una tormenta de preguntas comienza a surgir en tu mente. ¿Olvidaré cómo code? ¿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 pasé a ser líder de equipo. Lideré un equipo de seis personas. Trabajé en este rol durante 15 meses, y yo. Así que 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 texting consulting, una pequeña agencia de consultoría con sede en Berlín.

También soy un experto en varios formatos de JustJoin IT. También puedes encontrarme en sus redes sociales. Pero volviendo al tema, pequeña advertencia, estoy compartiendo exclusivamente mi perspectiva. Entonces, ¿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, la posición P5, era una gran organización. En el momento en que dejé la empresa, tenía 8,000 empleados. Teníamos una jerarquía multinivel y colaboración transgeográfica, Europa, Australia, EE. UU., India, y colaborábamos con muchos equipos en todo el mundo. Además, la empresa tenía una gran cultura de ingeniería y un gran apoyo para los ingenieros. Nota aparte, cuando menciono gerente, me refiero al rol en el que tenemos informes directos.

Entonces, ¿cuál era mi rol entonces? Yo 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 y tratemos de identificar el mío.

Así que tenemos tres áreas principales. La construcción de software, la estrategia y alineación, y la gestión de personas. El ciclo verde, que representa el rol con gestión de personas, son en realidad los roles gerenciales. Son los roles en los que tienes personas que te reportan, por más malo que suene. Y el líder técnico, el gerente de liderazgo técnico y el gerente de ingeniería pueden ser un poco confusos. Así que permíteme tratar de diferenciar entre esos dos. El gerente de liderazgo técnico es responsable de la tecnología, por ejemplo, de sistemas específicos y ellos mismos escriben el código. Es más probable que deleguen personas allí, que distribuyan tareas, pero aún así escriben software. Luego, a la derecha, el gerente de ingeniería es responsable del desarrollo de personas y su trabajo en equipo. ¿Qué más agregar? En la parte superior, puedes ver al ingeniero de personal, que también puede ser conocido como desarrollador principal o arquitecto. Y en el medio, hay una zona de peligro, donde se encuentran la mayoría de los CTO de las startups y los fundadores. Muchos sombreros para usar al mismo tiempo, pero este no es el tema de la charla de hoy. Y como ya mencionamos esos roles y esta diferenciación, debo agregar que el camino gerencial no es la única opción para obtener un ascenso después de ser un desarrollador senior, al menos en muchas empresas, gracias a Dios. Así que podemos seguir el camino de ingeniería y convertirnos en ingeniero de personal o ingeniero principal. Podemos seguir el camino gerencial. Podemos movernos entre esos roles o incluso cambiar completamente de rumbo. Y aquí está el ejemplo de GitLab. Puedes ver esos caminos aquí, el camino gerencial, que está en la parte superior, y el camino de ingeniería, siguen paralelos y casi hasta el último nivel, siguen en paralelo.

Pero volviendo al diagrama, mi rol era el de gerente de ingeniería. Tenía el equipo que me reportaba. Era responsable de organizar su trabajo, 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 y fuera de la empresa, de vez en cuando.

Tomé algunas decisiones técnicas de alto nivel con el apoyo de mi equipo, principalmente basadas en sus recomendaciones. Lo que ya no hacía era escribir el código yo mismo. Pero no estaba solo. Quiero decir, tanto en liderar al equipo como en el proyecto, lo estábamos llevando como un trío. Así que yo como gerente, el gerente de producto, la persona encargada del producto, más el diseñador de UX, la persona encargada del diseño. Y mi equipo también era parte de la organización más grande, así que tampoco estaba solo allí.

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. Era responsable de ¿cómo? Cómo lograr el objetivo y cuándo, como equipo. En resumen, debido a que había más responsabilidades. Por cierto, en la preparación para esta charla, hice una lista de temas que no iba a cubrir. ¿Y sabes qué? Accidentalmente escribí una lista de temas con los que tuve que lidiar como gerente de ingeniería, como la comunicación cruzada, el desarrollo de los miembros del equipo, ser parte del proceso de contratación, utilizar las estrategias de gestión adecuadas, y así sucesivamente. Perdón por el montón de títulos, pero me pareció bastante divertido.

Y hay un poco de eso, y puede ser un poco abrumador, especialmente al principio. ¿Entonces, cómo fue mi comienzo? Bueno, comenzamos el equipo con dos personas con las que 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 cinco a seis horas por semana, y muchos recursos externos. Tuvimos la oportunidad de recorrerlo, tuvimos sesiones con otros gerentes, sesiones con Recursos Humanos, sesiones de simulación de roles y ejercicios. Fue realmente genial y un gran apoyo. Para mí, fue un comienzo suave. Además, siempre puedes volver al rol de contribuyente individual. Con IC me refiero al rol de contribuyente individual. Si decides que esto no es para ti, ser gerente no es para ti, es una práctica común en las grandes empresas de tecnología. También empecé a participar en una gran cantidad de nuevas reuniones y conversaciones en Slack, pero en ese momento nadie requería mucha aportación o contribución de mi parte.

Fue más como una forma de aprendizaje por osmosis. Y en mi honesta opinión, ese comienzo suave fue realmente útil. Sí, pero hay peros, por supuesto. La palabra gerente, simplemente no encaja bien. No sientes que te represente. 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. Todo es muy vago. Al final, fue un conocimiento muy concreto y útil, pero como ingeniero, sonaba como tonterías, al menos al principio. También en ese momento, intenté escribir todo el code o intenté escribir algunas especificaciones técnicas, pero ya no hay opción para hacerlo cuando los temas se multiplican y el equipo crece. Así que sí, simplemente tengo que dejarlo ir.

Y empecé a preguntarme ¿qué estoy entregando realmente? ¿Entrego algo? Y esa 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 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, eso fue lo peor. Tienes que dar un paso atrás y entregar al equipo los temas que te encantaría abordar como ingeniero. Esos fueron realmente difíciles.

Y lo importante, lo más importante ahora 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. El equipo se convierte en el centro de gravedad. Si el equipo es el centro de gravedad, ¿qué te brinda, como gerente, satisfacción? Bueno, el éxito del equipo. Nuevos lanzamientos, innovaciones introducidas, publicaciones de blog, y así sucesivamente. Cuando ves que el equipo ve los objetivos y contribuye a ellos, cuando ves que la visibilidad y el rol 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 e independencia, 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... Un sorbo de agua también. Y hay una cosa que te preocupa. Me sentí genial cuando finalmente lo entendí. Es que como gerente, tienes un impacto mucho mayor en la organización que como desarrollador, porque ahora trabajas como equipo y el equipo está trabajando para lograr este objetivo y este impacto. Bueno, lo elogio 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 y también mi gerencia. Pero al mismo tiempo, extrañaba la práctica, extrañaba construir cosas, diseñar cosas. Simplemente extrañaba trabajar como ingeniero.

Recuerdo el momento en que me estaba preparando para uno de los programas matutinos con las últimas noticias, que solíamos grabar en ese momento, y estaba leyendo el artículo de Ryan Carnato, el creador de Solid.js, sobre las inconsistencias en la gestión de sitios locales en varios frameworks de JavaScript. Y me di cuenta de repente, oh Dios mío, no he trabajado con algo tan de bajo nivel durante un tiempo. De repente, los detalles de los componentes de React se volvieron de bajo nivel para mí. No el código ensamblador, los detalles de los componentes de React, lo cual está bien y es esperado para ti como gerente, porque no estás interesado en esos detalles hasta que eres, no sé, el gerente del equipo de React. Pero yo estaba 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 encantaba sumergirme y trabajar con los detalles. Sí, en ese momento, simplemente lo quería de vuelta.

Entonces, ¿fue exitoso mi experimento? ¿Qué aprendí? Que no se trata solo de ti. Siempre se trata del equipo. Aprendí a gestionar mejor el tiempo y las tareas, que el esfuerzo supera a los resultados, especialmente si estás evaluando el trabajo de otras personas. Que la retroalimentación, la seguridad y la sensación de objetivo son los fundamentos de un equipo saludable, siempre, independientemente del rol que tengas en ese momento. Y que un gerente no es un contador, no es una persona que solo siente el eje. Si eso es lo que sucede en tu organización, está perdiendo su objetivo. Y que aún no es posible volver al rol de manera unidireccional, incluso en la misma organización. Conozco personas que regresaron del rol de gerente al rol de desarrollador dentro de la misma empresa. Es más probable que lo hagas en diferentes equipos, especialmente si tienes una empresa más grande, entonces es más fácil de hacer. Y en general, ¿qué cambió para mí después de volver a ser desarrollador? Sí, ya lo sabes. Cambié de roles nuevamente. 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, estaba trabajando en el ecosistema de Jira y Atlassian, a básicamente la externalización. 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 volver al rol de contribuyente individual y mudarme a una empresa pequeña con una jerarquía plana, me llevó 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 técnico. No entraré en detalles. Estoy encantado de hablar de ello en línea o en el mostrador de café en la conferencia.

Así que al final, desde mi parte, aquí tienes algunos consejos para aquellos de ustedes que están comenzando como gerentes, o considerándolo como mis tres principales. Recuerda, no estás solo. Es útil hablar con otros gerentes. El segundo, tener reuniones individuales regulares con tu equipo y con tu gerente, tu supervisor. No dejes que las cosas se pierdan y sé abierto 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 equipo. Como empleado, como persona. Y siempre puedes volver al rol de ingeniería, al menos después de 15 meses, como lo hice yo. Por favor, califica el discurso, califica el discurso y dame tu opinión. Nosotros, los oradores, nos alimentamos de la retroalimentación. Me encantaría conocer tus opiniones sobre la charla y 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 los comentarios y enlaces. Siéntete libre de echarle un vistazo y jugar con ella. Y gracias una vez más. Que tengas una gran conferencia. Adiós.