Un día en la vida de un gerente de ingeniería: lo que la descripción del puesto no le cuenta

Son las 8:47 de la mañana. Su ingeniero on-call recibió una alerta a las 3:14 por una réplica de Postgres que se recuperó sola a las 3:22, lo que significa que durmió ocho minutos en lugar del resto de la noche. Su skip-level quiere una actualización de la hoja de ruta antes del mediodía y usted aún no ha abierto Notion. Tiene un 1:1 con un IC senior en 13 minutos para el que no se ha preparado, y el reclutador que lo colocó en este trabajo hace seis meses lo describió como "liderar un equipo de alto rendimiento".

Esa frase es cierta de la manera en que "administro un restaurante" es cierta cuando en realidad está haciendo inventario a las 11 de la noche y disculpándose con un cliente habitual por un pedido equivocado. Es el titular. El trabajo es todo lo que está debajo.

Esto es lo que el día realmente parece para un gerente de ingeniería con 5 a 12 subordinados directos en una empresa B2B SaaS. Marcas de tiempo reales, interrupciones reales, compromisos reales. Si usted es un IC que está sopesando el cambio, lea esto y pregúntese si suena como un trabajo que haría durante años. Si es un gerente de ingeniería actual que siente que está fallando porque su día no es más que interrupciones, lea esto y reconozca que no está fallando. Está haciendo el trabajo.

8:00 a. m., Preparación del standup, triaje de Slack y PagerDuty

Antes de que su equipo se conecte, usted hace el trabajo que nadie ve.

Abra PagerDuty. Revise los incidentes de la noche anterior. ¿Quién recibió alertas, qué se disparó, fue real o fue la misma alerta intermitente que marcó para limpieza hace tres sprints? Si fue real, su on-call necesita cobertura hoy; dígale en Slack que saltee el standup y duerma 90 minutos más. Si fue ruido, ese es un ticket para quien sea dueño de la observabilidad. De cualquier manera, decida antes del standup para poder absorber la interrupción en lugar de dejar que el equipo la cargue.

Luego Slack. Tiene 47 mensajes sin leer en seis canales. No los lee por contenido. Escanea dos cosas: quién está bloqueado y quién está frustrado. Los ingenieros bloqueados necesitan un camino despejado antes de las 10 a. m. o pierden medio día. Los ingenieros frustrados en hilos públicos necesitan un mensaje directo, no una respuesta pública, y ese mensaje probablemente deba ocurrir esta mañana.

Abra Linear. O Jira. Cualquiera que use su equipo, la pregunta es la misma: ¿qué tickets están atascados en revisión, cuáles están bloqueados por una dependencia fuera de su equipo, y cuáles parecen "en progreso" pero no se han movido en cuatro días? Esa última categoría es la peligrosa. Un ingeniero que no ha movido un ticket en cuatro días o está atascado y no lo dirá, trabajando en algo que no le informó, o mirando en silencio otros trabajos. Necesita saber cuál es el caso para el viernes.

No ha escrito código en tres semanas. Solía hacer esta parte del día con un café y un compilador. Ahora lo hace con un café y el contexto de siete personas cargado en su cabeza. El cambio de "yo escribo código" a "despejo caminos para 7 personas que escriben código" es lo primero que nadie le advierte, y es la parte que la mayoría de los ex-IC lloran en silencio durante los primeros seis meses.

9:00 a. m., El 1:1 para el que no se preparó

El 1:1 es sus 30 minutos de mayor palanca en la semana, y es lo primero que se sacrifica cuando la planificación del sprint se extiende. Hoy es con Maya, una ingeniera backend senior. Ha estado aquí tres años. Entregó su última gran migración. Y hace dos semanas su LinkedIn pasó silenciosamente de "abierto a oportunidades: no" a "abierto a oportunidades: sí".

No empiece por ahí. Empiece con: "¿Cómo está esta semana?" Y luego calle.

Un 1:1 real no es una actualización de estado. Las actualizaciones de estado ocurren en Linear y en el standup. El 1:1 es para todo lo que no cabe en un ticket: la retroalimentación que ella ha estado guardando, la decisión de arquitectura con la que no está de acuerdo, el hecho de que su manager (usted) no presionó lo suficientemente fuerte cuando el equipo de producto recortó a la mitad su rediseño. Su trabajo es hacer que sea seguro decir lo difícil, y luego actuar en consecuencia.

A las 9:18, PagerDuty se dispara. No es el servicio de su equipo, pero es suficientemente adyacente como para que Slack se ilumine. Echa un vistazo a su teléfono. Maya lo ve mirar. Aquí está el guion que funciona:

"Eso no es nuestro, pero Slack está a punto de ponerse ruidoso. Déme 20 segundos para silenciarlo, y luego continuamos. Su tiempo es más importante que ese hilo."

Luego realmente lo silencia. No escucha a medias durante los siguientes 12 minutos mientras sus ojos rastrean las notificaciones de Slack. El 1:1 obtiene toda su atención o lo cancela. No hay opción intermedia. La opción intermedia es cómo los ingenieros senior aprenden que su manager no está realmente presente, y así es como el LinkedIn de Maya pasa de "sí" a "acabo de aceptar una oferta".

10:30 a. m., Revisión de PR, pero no por corrección

Abre GitHub. O GitLab. Hay 14 PR abiertos en su equipo. No los está revisando por corrección. Su staff engineer revisa por corrección, y ahora es mejor en eso que usted.

Está revisando por flujo.

¿Quién ha esperado más de 48 horas para una revisión? Ese ingeniero está perdiendo impulso y probablemente está cambiando de contexto hacia otra cosa, lo que significa que cuando finalmente llegue la revisión, necesitarán una hora para volver al contexto. Encuentre al revisor, averigüe por qué está atascado, desbloquéelo.

¿Qué dos PR están tocando el mismo archivo? Eso es un conflicto de merge en gestación, y uno de esos ingenieros está a punto de perder una mañana en un rebase. Póngalos en una llamada de 10 minutos ahora.

¿Qué PR tiene seis rondas de comentarios de retoque en un cambio de 40 líneas? Eso es un ingeniero senior siendo demasiado cuidadoso con uno junior, y está erosionando la confianza en ambas direcciones. No comente en el hilo. Envíe un mensaje directo al senior: "Oye, el cambio se ve bien. Apruébalo y sigamos." Esa es la decisión que nadie más tomará, porque nadie más tiene la autoridad para tomarla.

GitHub es una herramienta de código para sus ingenieros. Para usted, es una superficie de gestión, un dashboard en tiempo real de dónde está atascada la atención, dónde la colaboración es fricción, y dónde la velocidad de entrega de su equipo se está escapando por los cuellos de botella de revisión. Llame a esto el impuesto de la cola de PR. Cada PR que lleva más de dos días le cuesta interés compuesto en enfoque perdido, y usted es la única persona cuyo trabajo es notarlo.

11:15 a. m., Planificación del sprint, luego la interrupción

Está 15 minutos dentro de refinar el tablero de Linear del próximo sprint con su tech lead. Está rechazando una historia que dice "investigar la migración del proveedor de autenticación" porque eso no es una historia, eso es un trimestre de trabajo disfrazado de tarde de martes.

Slack: "¿Tienes 2 minutos para una pregunta rápida?" Del VP de Producto.

Nunca son dos minutos. Nunca es una pregunta. La "pregunta rápida" es "estamos adelantando el lanzamiento de la función de IA tres semanas, ¿qué puede enviar realmente su equipo para entonces?" Esa respuesta requiere que usted conozca la capacidad de su equipo, sus compromisos de sprint existentes, la deuda técnica que está bloqueando la función de IA, las vacaciones de su ingeniero senior el mes que viene, y la realidad política de que decir "no, no podemos" es una frase que define la carrera y que solo puede usar algunas veces al año.

Toma la llamada. No da la respuesta en la llamada. Dice: "Déjeme revisar las dependencias y volver con un número real antes de las 4 p. m." Luego vuelve a la planificación del sprint a las 11:38 a. m. con su tech lead, que ha estado mirando educadamente su pantalla durante 23 minutos.

Este es el papel que ninguna descripción del puesto menciona: traductor de contexto. Usted se sienta entre la estrategia ejecutiva ("queremos IA para el tercer trimestre") y la realidad de ingeniería ("la migración de autenticación bloquea eso, y el ingeniero que conoce la autenticación está de permiso parental"). No puede decir que sí a ambos. Su trabajo es traducir uno en el otro de manera que no rompa la confianza en ninguna dirección. Algunas semanas lo hace bien. Algunas semanas lo hace mal y su equipo tiene latigazo. Ambas son normales.

1:00 p. m., La reunión consigo mismo que nunca ocurre

Después del almuerzo, su calendario muestra "ENFOQUE: documento de planificación T3". Ha estado ahí tres semanas. Se mueve cada día.

Este es el problema de la reunión con uno mismo. El trabajo que requiere pensamiento ininterrumpido (el plan trimestral de su equipo, sus evaluaciones de desempeño, la decisión de arquitectura que su staff engineer le escaló el viernes) nunca tiene una fecha límite urgente hoy. Así que siempre pierde ante el trabajo que sí la tiene. La alerta on-call. El mensaje directo del ingeniero que necesita cobertura. La "pregunta rápida" del VP.

La mayoría de los gerentes de ingeniería pierden esta batalla. El documento del tercer trimestre se escribe a las 11 p. m. del domingo porque su director lo necesita para el lunes por la mañana. Las evaluaciones de desempeño se comprimen en la semana anterior a su fecha límite, y se nota.

La solución no es glamorosa: reserve el bloque de enfoque en su calendario y trátelo como una reunión externa. Rechace las solicitudes que se superponen. Acepte que algunas semanas perderá el bloque ante un incendio real, y eso está bien, pero el valor predeterminado debe defenderse. Los ingenieros que se convierten en Senior EM y Director son los que aprendieron a proteger su propio tiempo de pensamiento antes de que se convirtiera en una crisis.

3:30 p. m., Notion asíncrono, no Slack en tiempo real

A media tarde, su cerebro está agotado. Este es el momento en que debería estar haciendo su trabajo de menor pensamiento y mayor volumen: escribir la documentación que vive en Notion y que no cambia nada de su día pero se acumula en los próximos dos trimestres.

La actualización del manual del equipo. El runbook on-call que su ingeniero pidió hace dos semanas. Las notas del retro del último sprint que prometió circular. El documento de calibración del proceso de contratación que su reclutador ha estado esperando.

Nada de esto es urgente. Todo es importante. El efecto compuesto es que seis meses después, cuando incorpore a un nuevo ingeniero, lea tres páginas de Notion y se ponga al día en una semana en lugar de hacerle las mismas preguntas a su tech lead durante un mes. Ese es el apalancamiento del trabajo escrito, y es invisible hasta que deja de hacerlo y observa cómo el equipo se ralentiza sin que nadie pueda señalar el porqué.

5:00 p. m., Trabajo en expedientes de ascenso

El equipo se está desconectando. Abre Notion. Está escribiendo dos expedientes de ascenso (uno para un ingeniero que va a Senior, uno para un ingeniero que va a Staff) y una autoevaluación para usted mismo.

Los expedientes de ascenso son el trabajo que se pospone todos los días hasta que la temporada de evaluaciones de desempeño llega como un camión. Y los ingenieros que ascienden son aquellos cuyos managers escribieron el caso durante todo el ciclo, con evidencia específica, no aquellos cuyos managers lo acumularon en un fin de semana con lenguaje vago sobre "impacto demostrado".

Aquí hay un fragmento de plantilla de Notion que realmente funciona:

## Caso de ascenso: [Nombre] → [Nivel]

### Qué cambió en el alcance (últimos 2 trimestres)
- [Proyecto específico, gestionado de principio a fin, con resultado medible]
- [Colaboración interfuncional específica con resultado nombrado]
- [Momento específico de mentoring con persona mentorada nombrada y resultado]

### Evidencia de que el siguiente nivel ya está ocurriendo
- [Enlace al documento de diseño que escribió]
- [Enlace al incidente que lideró]
- [Enlace a retroalimentación de un par o skip-level]

### Riesgos que el panel planteará (y respuestas)
- [Riesgo]: [Respuesta anticipada]
- [Riesgo]: [Respuesta anticipada]

### Solicitudes al panel
- [Qué necesita que ponderen más / menos]

La sección de riesgos y respuestas es la que la mayoría de los managers omiten. Es la que gana. Los paneles de ascenso son escépticos por defecto, y un expediente que anticipa sus objeciones hace el 80% del trabajo antes de que abran la boca.

Termina el primer expediente a las 5:51 p. m. Su hijo tiene un recital a las 7. Hará el segundo expediente mañana, excepto que mañana tiene un 1:1 que olvidó, una revisión de incidente y un panel de candidatos. Así que lo hará el jueves. Quizás.

El punto de inflexión de escala: de 5 a 9 ingenieros

Todo lo que acabo de describir funciona con 5 ingenieros. Se rompe con 9.

Con 5, puede tener todos los PR en la cabeza. Puede hacer 1:1 semanales con todos y aún tener tiempo para pensar. Sabe quién está atascado antes de que lo pregunte, porque puede verlo en el lenguaje corporal del standup.

Con 9, no puede. La matemática no funciona. Nueve 1:1 semanales de 30 minutos son 4.5 horas; con preparación y seguimiento, es un día completo. Los PR que antes revisaba de un vistazo ahora requieren el filtro de un tech lead antes de llegar a usted. Los standups dejan de ser señal y se convierten en teatro de estado porque hay demasiadas voces.

Los sistemas que ignoró con 5 se vuelven innegociables con 9: un manual del equipo escrito para que los nuevos miembros conozcan el estándar, una rotación on-call que no dependa de su memoria, un criterio de contratación que viva fuera de su cabeza, y 1:1 que pasan a quincenal para las personas más senior porque lo necesitan menos y semanales para las personas más nuevas en el equipo o más nuevas en el nivel senior.

Cuando hace el cambio a quincenal, alguien se siente descuidado. Dígale directamente el porqué. "Estoy más estirado de lo que estaba. El quincenal es lo que puedo sostener. Si surge algo urgente, mi mensaje directo en Slack está abierto y respondo en menos de una hora." La honestidad le compra más buena voluntad de la que le cuesta los 30 minutos faltantes.

Lo que la descripción del puesto se equivocó

"Liderar un equipo de alto rendimiento" realmente significa:

• Proteger su enfoque. La mayor parte de su día consiste en absorber el caos para que ellos no tengan que hacerlo.
• Traducir la ambigüedad. La estrategia ejecutiva es vaga a propósito. Su equipo necesita tickets, no sensaciones.
• Defender su tiempo. Decir no a la "pregunta rápida" del VP es parte del trabajo, no evitar el trabajo.
• Escribir el documento que nadie más escribirá. Runbooks, manuales, expedientes de ascenso, resúmenes de retro.
• Absorber el estrés para que ellos no tengan que hacerlo. Este es el núcleo no glamoroso del rol y la parte que agota a las personas.

La descripción del puesto dice "impulsar resultados". El día dice "escribir la página de Notion que significa que la próxima persona no tiene que descubrir esto desde cero".

Cierre

Si todo en este artículo suena energizante (el 1:1 al que realmente esperaría con anticipación, el caos que disfrutaría traducir, la acumulación lenta de documentación escrita que nadie más hará), está listo.

Si suena agotador (preferiría entregar código en lugar de absorber reuniones, preferiría resolver problemas técnicos difíciles en lugar de problemas humanos), la trayectoria de IC no es una degradación. Es una forma diferente de trabajo senior, y la industria finalmente la está recompensando adecuadamente. La descripción del puesto de Staff Software Engineer es el complemento de este artículo por una razón. Lea ambos. Elija el que cuyas partes difíciles esté dispuesto a vivir durante los próximos cinco años.

La respuesta correcta es aquella en la que los días malos aún se sienten como un trabajo que vale la pena hacer.

Aprenda más

• JD complementario de Staff Software Engineer
• Cómo conducir 1:1s que los ingenieros no temen
• La transición de IC a gerente de ingeniería
• Cómo escribir expedientes de ascenso que realmente funcionan