Después de convertirse en gerente, ¿cómo continúa manteniendo sus habilidades técnicas?

Answer 1

Como gerente de un equipo suficientemente grande, se supone que no debes codificar. He asesorado a muchos gerentes de ingeniería recientemente promovidos y siempre les digo esto: una vez que el equipo es más grande que ~ 4 personas, deben esperar no codificar y resistir la necesidad de hacerlo.

La razón aquí es porque cuando su equipo está bajo presión (por ejemplo, fecha de entrega), un gerente joven puede verse tentado a regresar a su zona de confort para resolver el problema. Es decir, en lugar de hacer lo difícil (y en el momento aparentemente arriesgado) de organizarse mejor, motivar al equipo, o cualquier cosa de “gerente” que necesiten hacer, simplemente se arremangarán, se quedarán tarde y llevarán el proyecto a través de la línea de meta escribiendo código. La razón por la que esto es malo es porque en momentos difíciles como ese es exactamente cuando un nuevo gerente necesita aprender a administrar de manera efectiva y evitar volver a usar su antiguo conjunto de habilidades. Si recurren al uso de sus habilidades técnicas para ayudar a su equipo, nunca aprenderán a convertirse en un administrador efectivo . Este es un punto crítico de bifurcación que separa a los antiguos ingenieros que terminan convirtiéndose en buenos gerentes frente a los que no lo hacen.

A pesar de esto, sigue siendo bastante sencillo mantener sus habilidades técnicas.

Lo primero es que realmente no necesita preocuparse demasiado por perder su ventaja. Si fue bueno para empezar, probablemente no se oxidará tanto como cree. Después de estar en una posición gerencial por más de 2 años (y preocupado por este problema), me uní a otra compañía y volví a una función de codificación directa donde descubrí que, extrañamente, mis habilidades técnicas habían mejorado . Si usted es un gerente de ingeniería involucrado, aparentemente pensar en la administración de software desde un nivel de equipo más amplio ayuda a unir ciertos conceptos generales de una manera de nivel superior que contribuye a una mejor práctica personal cuando regresa a ella. Por otro lado, no sé si esto es cierto si estás continuamente en funciones de gestión durante algo así como 10 años.

La segunda forma es simplemente codificar. Sin embargo, no debe escribir código para ninguno de los proyectos críticos de su equipo que están en una línea de tiempo de entrega. Es decir, nunca debe contribuir con el código que su equipo “necesita”. Esto es según la parte anterior de mi respuesta: para los proyectos que su equipo necesita entregar, debe contribuir a ellos aprendiendo a administrar de manera efectiva , no escribiendo código. En cambio, debe escribir herramientas internas o código para proyectos no críticos (quizás de manera informal para otro equipo). Estos pueden ser tan sofisticados desde el punto de vista técnico como el código que se está escribiendo para los proyectos críticos de fecha límite o comercial, por lo que no debe preocuparse de que no esté obteniendo experiencia con las tecnologías o algoritmos correctos. O bien, puede trabajar en proyectos técnicos no relacionados en su tiempo libre en casa. Por casualidad elegí esta ruta la primera vez que fui gerente: en mis horas libres, creé una startup y aprendí un nuevo idioma y un montón de cosas sobre escalabilidad y bases de datos.

Entonces, la forma de mantener sus habilidades técnicas es exactamente la forma en que siempre lo ha hecho: escriba el código. Simplemente no escriba código para su equipo .

Answer 2

Idealmente, un gerente debe estructurar su equipo de manera que pueda funcionar sin que sea un cuello de botella crítico.

Si bien ser gerente (de cualquier grupo más grande que digamos 3 a 4) en una empresa de varias organizaciones requeriría que manejes una variedad de trabajos no técnicos, como reclutamiento, gestión de proyectos / entregables, gestión de personal, por nombrar algunos, todavía deja muchas oportunidades para seguir siendo altamente técnico.

Por ej.

• Contribuya con el código a las características periféricas que no son críticas / tienen plazos estrictos. Todos los proyectos tienen algunos de estos que entran en la categoría “haremos esto si alguna vez tenemos tiempo”
• Escriba un código que utilice las características que su equipo está creando. es decir, actuar como su propio cliente. Esto tiene dos beneficios. Terminas probando el código de tu equipo y entiendes por lo que pasan tus clientes reales (usuarios de las ofertas de tu equipo) para que puedas tener una mejor perspectiva. Nuevamente, esto se puede hacer si / cuando el tiempo lo permite y no obstaculiza la entrega del equipo.
• Hacer revisiones de código. Estas son excelentes oportunidades para estar en contacto con lo que su equipo está desarrollando. Del mismo modo en las revisiones de diseño.
• Tinker en casa / proyectos de mascotas en el lateral.

La codificación es solo un aspecto de la ingeniería de software.

Ser un gerente técnico implica tener las habilidades técnicas y mantenerlo, al tiempo que reconoce que la responsabilidad principal es liderar / administrar el equipo y sus resultados. Nunca pierdas el foco en lo que tu rol aporta a la organización. (Esto difiere en diferentes organizaciones y situaciones)

Answer 3

Me gusta la respuesta de Yishan Wong, pero estoy empezando a sentir que sueno como un disco roto sobre XP.

Si bien estoy de acuerdo en que los gerentes no deberían volver a la codificación porque es cómodo, una vez más, creo que la programación por pares hace que la * codificación de los gerentes * sea muy fácil.

Si hace ejercicio o tiene tiempo para hacer una inmersión profunda, simplemente siéntese con uno de sus ingenieros y empareje con ellos por el resto del día.

Puede agregar mucha información, aprender sobre lo que está sucediendo en el nivel más bajo y no dejar al equipo en apuros cuando tiene que saltar.

Answer 4

En lugar de hacer la tarea, el trabajo del gerente es administrar el trabajo y supervisar a los trabajadores. Esto podría significar revisar el trabajo terminado, aprobar y reforzar el buen trabajo, enseñar y corregir donde sea necesario. Nunca rebaje a un supervisor que trabaja para usted. Elogie en público, reconociendo que el supervisor junior obtiene crédito por el buen trabajo de aquellos que supervisa; Corrija o aplique comentarios negativos en privado. Alcanzar más de un nivel hacia abajo es destructivo de la función y la moral en una organización. Puede enseñar, pero eso sería en beneficio de los trabajadores en múltiples niveles. Bien podría servir como modelo a seguir y figura líder.