Qué debería gestionar realmente un Engineering Manager

Quien empieza a gestionar suele heredar un calendario, no un puesto. Dailies, planificación, escalados, one-to-ones, informes de estado, seguimiento de incidencias. Es perfectamente posible pasar un trimestre completamente ocupado sin haber gestionado nada que importara.

La pregunta útil no es qué hace un engineering manager, sino qué se degradaría si nadie fuera su dueño. En mi experiencia hay cuatro cosas así, y ninguna es repartir tickets.

Las personas y la forma del equipo

Quién está en el equipo, en qué es bueno, en qué quiere convertirse y si el conjunto tiene el rango necesario para ser dueño de su dominio. Es trabajo lento: contratar, incorporar, dar feedback honesto pronto y no en la evaluación anual, y abrir caminos a quien quiere más alcance.

Un manager que deja esto a la deriva puede parecer eficaz dos trimestres. La factura llega después, cuando se va el ingeniero más sólido y nadie más entiende el sistema de pagos.

Claridad de propósito

Un equipo debería poder explicar de qué es dueño, quiénes son sus clientes y qué significa tener éxito este trimestre, sin abrir una presentación. Si los ingenieros no pueden responder a eso, el manager no ha terminado de traducir la estrategia en algo accionable.

La mayoría de los equipos no son lentos porque la gente trabaje despacio, sino porque el trabajo era ambiguo cuando empezó.

El sistema en el que trabaja el equipo

Tiempos de build, tests inestables, entornos que cuesta levantar, fricción de despliegue, latencia de revisión, carga de guardias, número de equipos con los que hay que coordinarse para entregar un cambio. Los ingenieros sufren esto cada día y casi nunca tienen autoridad para arreglarlo todo.

Aquí es donde un manager crea una palanca que sobrevive a cualquier sprint. Reducir un ciclo de feedback de dos días a veinte minutos cambia cómo piensa un equipo, no solo lo rápido que teclea.

Confianza en las dos direcciones

Hacia arriba, el manager es dueño de una imagen creíble de a qué puede comprometerse ingeniería y a qué no. Hacia abajo, el equipo necesita saber que las malas noticias llegan a dirección sin lijar y que la presión no se transmitirá sin filtrar.

Lo que un manager no debería gestionar

• Cada decisión técnica: marca dirección y estándares y deja decidir al equipo
• La asignación individual de tareas cuando el equipo puede tirar del trabajo
• Ser la única interfaz con el resto de la compañía
• Su propia imprescindibilidad

La prueba que aplico es sencilla: si me ausento dos semanas, ¿qué se rompe? Lo que se rompa es o algo que debería haber sistematizado, o algo que debería haber enseñado a otra persona. Ambas respuestas apuntan lejos de hacer más y cerca de gestionar mejor.