Un Cuento de los Cambiantes. De Ingeniero a Gerente y Viceversa

Rate this content
Bookmark
Slides

He cambiado entre ser ingeniero y gerente tres veces ya. Soy muy consciente de que esto no es algo inusual de hacer. ¡Hay un montón de cambiantes por ahí! En Atlassian estoy en un nuevo grupo de gerentes. Curiosamente, hay muchos gerentes en el grupo que han sido gerentes anteriormente pero se unieron a Atlassian como ingeniero.
Entonces, ¿qué nos pasa? ¿Por qué seguimos cambiando nuestro rol? ¿Es aburrimiento? ¿Estamos locos? Creo que en realidad hay un método en la locura. Cada vez que hacemos un cambio es intencional y hay un propósito, y aunque algunos dicen que puede dañar tu carrera, me gustaría llevarte en un viaje para explorar por qué los cambiantes son una raza muy valiosa!

FAQ

Matt Coleman ha alternado varias veces entre roles de ingeniería y de gestión a lo largo de su carrera, trabajando en empresas como Blake, Play Up, Domain y Atlassian, y gestionando equipos de diversos tamaños.

Matt Coleman cree que alternar entre ingeniería y gestión puede ser un excelente movimiento de carrera porque permite mejorar diferentes habilidades que son transferibles entre ambos roles, haciendo a la persona más versátil y valiosa.

En Play Up, Matt Coleman aprendió React, una tecnología que le interesaba y que añadió a su conjunto de habilidades como desarrollador.

En Atlassian, los movimientos laterales son bastante alentados, lo que permite a los empleados explorar diferentes roles y responsabilidades sin necesariamente buscar una promoción, pero sí un crecimiento horizontal en sus carreras.

Matt Coleman destaca que tener experiencia tanto en gestión como en ingeniería permite tener conversaciones más profundas y significativas dentro de los equipos, además de impulsar el liderazgo desde diferentes niveles, no solo desde la gestión.

Matt Coleman sugiere que si un gerente aún puede contribuir efectivamente al código sin afectar sus responsabilidades de gestión, debería hacerlo, especialmente si eso ayuda a cumplir con plazos o a construir relaciones a través de la programación en pareja.

Matt Colman
Matt Colman
7 min
12 Dec, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Esta charla explora la experiencia de cambiar entre ser un ingeniero y un gerente en el campo del desarrollo de software. Enfatiza la importancia de mantener habilidades técnicas prácticas para una gestión de ingeniería efectiva. La charla también destaca el valor de que los gerentes tengan experiencia técnica reciente y la importancia del liderazgo tanto de los gerentes como de los ingenieros senior. En general, la charla anima a aquellos que están considerando una transición a la gestión a que lo hagan y enfatiza el papel único de un gerente de ingeniería.

1. Cambio constante entre ingeniero y gerente

Short description:

Hola, soy Matt Coleman, un gerente de ingeniería en Atlassian, emocionado de hablar sobre el cambio constante entre ser ingeniero y gerente. Es un buen movimiento de carrera. Comencé como desarrollador, me convertí en gerente, aprendí React, extrañé ser gerente, volví a ser gerente. Esta charla es para aquellos que cambian constantemente, aquellos que consideran la gestión, y los gerentes que extrañan la codificación.

Hola, soy Matt Coleman. Soy un gerente de ingeniería en Atlassian. Y estoy muy emocionado de estar aquí hoy en el Día de React en Berlín para hablarles sobre el cambio constante entre ser ingeniero y gerente. Ahora, eso es algo que he hecho muchas veces en mi carrera. Probablemente tengo algunos más en mí para ser honesto. Pero no estoy loco. Sabes, esto es algo que la gente realmente hace. Y quiero hablarles sobre cómo es en realidad un muy buen movimiento de carrera.

Entonces, echemos un vistazo a mi carrera. Esta es, en una imagen. Comencé en Blake como un Y unos dos o tres años después, me ofrecieron un ascenso a la gestión. Y así ahí estaba, dirigiendo a unos cuatro desarrolladores y eso se convirtió en 10. Un trabajo realmente genial. Me encantó. Pero comencé a extrañar un poco el código. Y estaba muy interesado en React. Así que, fui a Play Up, y aprendí React. Y luego, unos años después, extrañé un poco tener el impacto que tiene un gerente. Así que, me mudé a Domain como gerente. Luego a Atlassian como desarrollador, donde de nuevo, aprendí algunas nuevas tecnologías, GraphQL, Relay, un montón de otras cosas diferentes que no conocía. Y luego, una vez más, me ofrecieron un puesto como gerente. Esta vez fue un movimiento lateral en Atlassian. Y en Atlassian, el movimiento lateral es bastante alentado. Así que, hay muchos que cambian constantemente en Atlassian.

Ahora, ¿para quién es esta charla? Bueno, es para los que cambian constantemente, por supuesto. Y también, sabes, si estás pensando, podría ser un buen gerente, no estoy seguro. Entonces esta charla es para ti. O tal vez ya eres un gerente y extrañas ser un desarrollador. Extrañas el código. Así que,

2. Amantes de los perros y el papel de un gerente de ingeniería

Short description:

Amantes de los perros, esta charla es para ustedes. Los mejores gerentes de ingeniería de primera línea nunca están más de dos o tres años alejados del trabajo práctico. Los mejores contribuyentes individuales son los que han pasado tiempo en la gestión. Si estás gestionando personas y escribiendo código, estás haciendo un mal trabajo en ambos. Si estás gestionando a tres desarrolladores, entonces probablemente deberías estar escribiendo código. Si estás gestionando a ocho desarrolladores, tu velocidad ya no es significativa. Todavía hay razones por las que podrías escribir código como gerente. Convertirse en un gerente de ingeniería es un papel completamente diferente.

esta charla es para ti. Amantes de los perros, esta charla es para ustedes. Quiero decir, esta charla tiene algo para todos. Ahora bien, la segunda vez que hice un cambio, un amigo mío me dijo, oh, ¿has visto la publicación del blog del péndulo del gerente de ingeniería de Mipsy Tipsy? Y no lo había hecho, pero lo revisé. Es una lectura de dos minutos y es fantástica. Quiero decir, realmente resonó conmigo cuando leí este blog. Y hay algunas citas geniales aquí. Permíteme leer una para ti. Los mejores gerentes de ingeniería de primera línea en el mundo son aquellos que nunca están más de dos a tres años alejados del trabajo práctico. A tiempo completo, en las trincheras. Los mejores contribuyentes individuales son aquellos que han pasado tiempo en la gestión. No podría estar más de acuerdo, vayan y revísenlo. Es un gran blog.

Muy bien, cosas que la gente tuitea. Todavía se llama Twitter, y todavía se llama un tuit. Entonces, si estás gestionando personas y escribiendo código, entonces estás haciendo un mal trabajo en ambos. ¿Alguna vez has oído esto antes? Mira, es un gran tuit, pero a Twitter le falta mucho contexto. Entonces, sabes, en realidad tal vez no sea un gran tuit. Es un poco confuso para algunas personas. Yo diría que si estás gestionando a tres desarrolladores, entonces probablemente deberías estar escribiendo código, porque no tendrás suficiente trabajo para hacer de otra manera, y probablemente solo pasarás tu tiempo molestando a los tres desarrolladores. Así que sigue escribiendo código. Sin embargo, si estás gestionando a ocho desarrolladores, entonces tienes que entender que tu velocidad ya no es realmente significativa. Tienes suficientes desarrolladores para escribir código. Entonces, no escribirías código para la velocidad. Pero todavía hay otras razones por las que podrías escribir código. En pocas palabras, si lo mejor que puedes hacer ese día es escribir código, entonces deberías hacerlo. Entonces, podrías tener un plazo realmente difícil, o podrías querer programar en pareja con alguien para construir relaciones o para aprender. Todavía hay un montón de razones por las que puedes escribir código como gerente. Y yo digo, adelante. Convertirse en un gerente de ingeniería es un papel completamente diferente.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Un Marco para Gestionar la Deuda Técnica
TechLead Conference 2023TechLead Conference 2023
35 min
Un Marco para Gestionar la Deuda Técnica
Top Content
Seamos realistas: la deuda técnica es inevitable y reescribir tu código cada 6 meses no es una opción. La refactorización es un tema complejo que no tiene una solución única para todos. Las aplicaciones de frontend son particularmente sensibles debido a los frecuentes cambios de requisitos y flujos de usuario. Nuevas abstracciones, patrones actualizados y limpieza de esas viejas funciones - todo suena genial en papel, pero a menudo falla en la práctica: los todos se acumulan, los tickets terminan pudriéndose en el backlog y el código legado aparece en cada rincón de tu base de código. Por lo tanto, un proceso de refactorización continua es la única arma que tienes contra la deuda técnica.En los últimos tres años, he estado explorando diferentes estrategias y procesos para refactorizar el código. En esta charla describiré los componentes clave de un marco para abordar la refactorización y compartiré algunos de los aprendizajes acumulados en el camino. Espero que esto te ayude en tu búsqueda de mejorar la calidad del código de tus bases de código.

Principios para Escalar el Desarrollo de Aplicaciones Frontend
React Summit 2023React Summit 2023
26 min
Principios para Escalar el Desarrollo de Aplicaciones Frontend
Top Content
Después de pasar más de una década en Google, y ahora como el CTO de Vercel, Malte Ubl no es ajeno a ser responsable de la infraestructura de software de un equipo. Sin embargo, estar a cargo de definir cómo las personas escriben software, y a su vez, construir la infraestructura que están utilizando para escribir dicho software, presenta desafíos significativos. Esta presentación de Malte Ubl revelará los principios guía para liderar una gran infraestructura de software.
Luchando contra la Deuda Técnica con la Refactorización Continua
React Day Berlin 2022React Day Berlin 2022
29 min
Luchando contra la Deuda Técnica con la Refactorización Continua
Top Content
Afrontémoslo: la deuda técnica es inevitable y reescribir tu código cada 6 meses no es una opción. La refactorización es un tema complejo que no tiene una solución única para todos. Las aplicaciones de Frontend son particularmente sensibles debido a los frecuentes cambios de requisitos y flujos de usuario. Nuevas abstracciones, patrones actualizados y limpieza de esas viejas funciones - todo suena genial en papel, pero a menudo falla en la práctica: los todos se acumulan, los tickets terminan pudriéndose en el backlog y el código legado aparece en cada rincón de tu base de código. Por lo tanto, un proceso de refactorización continua es la única arma que tienes contra la deuda técnica. En los últimos tres años, he estado explorando diferentes estrategias y procesos para refactorizar el código. En esta charla describiré los componentes clave de un marco para abordar la refactorización y compartiré algunos de los aprendizajes acumulados en el camino. Espero que esto te ayude en tu búsqueda de mejorar la calidad del código de tus bases de código.
Construyendo equipos interculturales de alto rendimiento
React Day Berlin 2022React Day Berlin 2022
25 min
Construyendo equipos interculturales de alto rendimiento
Todo lo que hacemos, desde la forma en que escribimos nuestros correos electrónicos hasta la manera en que proporcionamos retroalimentación negativa y evaluamos el rendimiento, influye en el desempeño de nuestros equipos. Y comprender cómo la cultura impacta nuestra eficacia como equipo puede mejorar drásticamente nuestra colaboración diaria. En esta sesión aprenderás: Cómo se comunican diferentes culturas, Cómo diferentes culturas evalúan el rendimiento y dan críticas constructivas, Cómo diferentes culturas toman decisiones, Cómo diferentes culturas confían, Cómo diferentes culturas perciben el tiempo.
Escala tu aplicación de React sin micro-frontends
React Summit 2022React Summit 2022
21 min
Escala tu aplicación de React sin micro-frontends
A medida que tu equipo crece y se convierte en múltiples equipos, el tamaño de tu base de código también crece. Llegas a las 100k líneas de código y el tiempo de compilación se acerca peligrosamente a los 10 minutos 😱 Pero eso no es todo, tus verificaciones estáticas de CI (linting, cobertura de tipos, código muerto) y pruebas también están tardando cada vez más...¿Cómo puedes mantener a tus equipos avanzando rápidamente y enviando funciones a los usuarios de manera regular si tus PRs tardan una eternidad en ser probados y desplegados?Después de explorar algunas opciones, decidimos seguir el camino de Nx. ¡Veamos cómo migrar una gran base de código a Nx y aprovechar sus compilaciones incrementales!
Una Guía Rápida y Completa para Medir tu Deuda Técnica y Utilizar los Resultados
TechLead Conference 2023TechLead Conference 2023
27 min
Una Guía Rápida y Completa para Medir tu Deuda Técnica y Utilizar los Resultados
Casi nadie en el mundo de la tecnología disfruta cuando hay mucha deuda técnica. Y a la mayoría de nosotros nos gustaría que no haya demasiada. Pero, ¿cómo entendemos cuánta tenemos exactamente? ¿Dónde se encuentra exactamente? ¿Qué parte de ella es realmente la más molesta? ¿Cuál sería el beneficio para nosotros si dedicamos tiempo a deshacernos de ella? Cuando se trata de planificar cómo abordar tu deuda técnica, todas estas preguntas merecen respuestas. Especialmente cuando nos preguntan sobre el retorno de la inversión en nuestros esfuerzos para eliminar cosas antiguas molestas y construir un nuevo módulo o servicio brillante. Además, cuando trabajamos en la deuda técnica, queremos abordar primero las partes más impactantes, ¿verdad? Esta charla trata sobre todo eso: cómo medimos nuestra deuda técnica, cómo interpretamos los resultados de estas mediciones para que nos den las respuestas a las preguntas correctas, y cómo guiamos nuestra toma de decisiones con esas respuestas.