Errores comunes del gerente de ingeniería (y cómo dejar de cometerlos)

Es domingo por la noche. Está revisando un PR que su staff engineer abrió el viernes porque nadie más "tenía el contexto". Su documento de 1:1 con su subordinado directo más senior tiene los mismos tres puntos que tenía hace seis semanas. No ha hecho un retro desde la reorganización. Se dice a sí mismo que es un manager de coaching. Su equipo lo describiría como "bueno pero ausente".

Esta guía es la brecha.

He sido el mal gerente de ingeniería en cada una de estas historias. No voy a moralizar. Voy a nombrar el patrón, darle el número que cuantifica el daño y decirle exactamente qué hacer esta semana. Puede leer a Lara Hogan, Will Larson y Camille Fournier todo el año, pero hasta que metabolice el consejo en comportamiento cambiado un martes por la mañana, su equipo sigue sufriendo la versión de usted que no ha leído nada de eso.

Por qué esto importa ahora

Los gerentes de ingeniería en su primer año son evaluados en dos cosas: rendimiento del equipo y retención del equipo. La mayoría falla en retención porque los modos de fallo son invisibles hasta que alguien renuncia. Para entonces, son 3 meses de reemplazo, 6 meses de adaptación y aproximadamente entre $180K y $250K en costo total por salida cuando se suman compensación completa del ingeniero, honorarios de reclutadores y el arrastre en la adaptación del equipo que dejaron atrás.

Dos salidas lamentables en un año borran la mayor parte del incremento de productividad que entregó. Y no puede gestionar lo que no ve, así que el primer trabajo es nombrar los patrones. Aquí están los siete que aparecen con más frecuencia en gerentes de ingeniería de entre 6 y 18 meses.

Error 1: Programar en lugar de hacer coaching

Síntoma. Está cerrando entre 3 y 8 PR propios a la semana. Se dice a sí mismo que está "desbloqueando al equipo". En realidad está evitando el trabajo más difícil y lento de decidir qué persona del equipo debe crecer en esa parte del código.

Número real. Cada hora que pasa programando son aproximadamente 1.5 a 2 horas de coaching al equipo que se pierden, porque el coaching es impulsado por interrupciones y ahora está con la cabeza gacha y no disponible. Para un equipo de seis personas, eso son aproximadamente 10 horas de coaching perdidas a la semana. En un trimestre, ha robado aproximadamente 130 horas, o un sprint completo de tiempo de desarrollo senior, del crecimiento de sus subordinados directos.

Solución. Limite su contribución como IC al 10% de su semana. Bloquéelo en su calendario, etiquételo "tiempo de IC" y cuando el tiempo se acabe, se acaba. Entregue la próxima tarea de "solo voy a hacer esta" al subordinado directo en cuyo área de crecimiento toca, y dígale por qué se la está entregando: "Este es el tipo de trabajo que lo lleva al siguiente nivel. Quiero que sea el dueño, y quiero revisar el diseño antes de que empiece." Esa última oración es la diferencia entre una entrega y un abandono.

Error 2: Evitar el 1:1 difícil

Síntoma. Su 1:1 semanal con el senior que entrega pero es tóxico en la revisión de código sigue "quedándose sin tiempo" antes de que usted aborde el comportamiento. Tres meses después, dos personas del equipo están entrevistando en otro lugar.

Número real. Permanencia promedio de un ingeniero que tiene un compañero que considera tóxico y un manager que no ha abordado el tema: 8 a 11 meses. Permanencia promedio de un ingeniero cuyo manager nombró el comportamiento dentro de las primeras cuatro semanas: 2.5 años o más. La diferencia es el costo completo de un reemplazo por cada año de evasión, más el costo cultural en el resto del equipo que lo vio no actuar.

Solución. Si ha estado evitando un tema durante dos semanas o más, el próximo 1:1 empieza con eso. Sin preámbulos, sin "¿cómo estuvo tu fin de semana?". Guion: "Quiero usar los primeros 15 minutos para una conversación difícil sobre cómo va la revisión de código. He escuchado X de dos compañeros. Cuénteme su perspectiva." No suavice la apertura. Suavice la escucha. La razón más común por la que esta conversación sale mal no es que dijo lo incorrecto. Es que dijo lo correcto durante 30 segundos y luego pasó los siguientes 14 minutos disculpándose por ello.

Error 3: Depender demasiado de las métricas de velocidad de entrega

Síntoma. Cita story points en las reuniones con su skip-level. Celebró un aumento del 20% en velocidad de entrega el trimestre pasado que vino de que un senior repunteó el backlog, no de ningún cambio en el rendimiento real. Cuando le preguntan cómo va el equipo, "la velocidad está arriba" es lo primero que sale de su boca.

Número real. Aproximadamente el 70% de los cambios de velocidad de entrega en un trimestre dado son deriva de estimación, no un cambio real de productividad. Los equipos que gestionan por velocidad de entrega ven aumentar la tasa de fallos en cambios DORA entre un 15 y un 25% en dos trimestres, porque recortan la profundidad de pruebas y el rigor de revisión para mantener el número de puntos atractivo. Optimizó el dashboard y dañó el sistema que hay debajo.

Solución. Reemplace la velocidad de entrega en su reporte semanal con tres números: frecuencia de despliegue, tasa de fallos en cambios y tiempo de recuperación. Si su organización no los rastrea, instrumenételos usted mismo en una hoja de cálculo durante un trimestre. Tarda unos 90 minutos en configurar y 10 minutos a la semana en mantener. Lleve las métricas DORA a su skip-level y explique por qué está alejándose de los puntos. La primera vez que lo haga, su skip-level lo respetará más, no menos. Deje de citar los puntos.

Error 4: Documentar insuficientemente los criterios de ascenso

Síntoma. Tiene un subordinado directo que "parece estar cerca" del nivel senior y otro que "todavía no llega". Si alguien le pidiera escribir la diferencia entre ellos en 90 segundos, no podría. Hablaría de "presencia" y "ownership" y "juicio" y la sala asentiría educadamente.

Número real. Los resultados de ascenso se correlacionan alrededor de 0.4 con criterios documentados y alrededor de 0.7 con la confianza del manager y el sesgo de recencia cuando los criterios no están escritos. La brecha aparece en la calibración como "confío en su evaluación", que es cómo los que hacen más ruido ascienden y los tranquilos se estancan. El costo cae sobre el equipo unos 18 meses después, cuando el IC más fuerte, que fue descartado sin una razón clara, se va a una empresa que sí se la dio.

Solución. Esta semana, escriba un documento de una página "qué parece staff en este equipo". Tres secciones: alcance, impacto, comportamientos. Ponga de 4 a 6 ejemplos concretos en cada sección, tomados de personas que ascendería mañana. Compártalo con cada subordinado directo en su próximo 1:1, no en un vago correo de "aquí está el documento, avíseme si tiene preguntas". Guíelos a través de él. Pregúnteles dónde creen que están. Use el mismo documento en la calibración. Actualícelo trimestralmente. El documento no es el objetivo; la conversación que fuerza es el objetivo.

Error 5: Proteger al equipo del contexto (mal)

Síntoma. "Protege al equipo de la política" al no decirles que el proyecto está en riesgo, la plantilla está congelada o el cliente odia el v1. Se enteran por un canal de Slack dos semanas después, a menudo de alguien que ni siquiera trabaja en su equipo. Luego le preguntan al respecto y usted dice algo como "Sí, iba a mencionar eso".

Número real. Los ingenieros que se sienten mal informados obtienen entre 30 y 40 puntos menos en las encuestas de compromiso que los compañeros que se sienten bien informados. El compromiso en el cuartil inferior predice la rotación dentro de los 12 meses a 2 a 3 veces la tasa base. Traducción: la mala protección le cuesta aproximadamente uno de cada cuatro subordinados directos por año, y los cuatro que pierde son los cuatro con opciones.

Solución. Por defecto, comparta. La prueba no es "¿esto los estresará?", sino "¿querría saber esto si fuera uno de ellos?" Haga un standup de contexto semanal de 15 minutos del equipo: qué cambió a nivel de liderazgo, qué sigue siendo incierto, qué deben ignorar. Si algo es genuinamente demasiado sensible, diga "hay algo que no puedo compartir todavía, aquí está cuándo espero poder hacerlo". Esa oración compra más confianza que cualquier eufemismo. Los ingenieros pueden notar la diferencia entre un manager que los protege y un manager que se protege a sí mismo.

Error 6: No hacer retros (o hacer retros falsas)

Síntoma. El último retro fue hace 11 semanas. O sí los hace, pero las acciones nunca tienen dueños ni fechas límite, así que los mismos tres problemas aparecen en cada retro para siempre. Alguien menciona que los deploys siguen siendo dolorosos. Todos asienten. No pasa nada. Siguiente retro, alguien menciona que los deploys siguen siendo dolorosos. Todos asienten.

Número real. Los equipos que hacen retros reales, con dueños nombrados y fechas y seguimiento en el próximo retro, entregan aproximadamente un 25% más de trimestres sin incidentes que los equipos que no los hacen. Los equipos que hacen retros falsas obtienen el mismo resultado que los equipos que hacen cero, lo que significa que el ritual sin el bucle es activamente peor que nada. Ha enseñado al equipo que plantear problemas no los soluciona, lo cual es una lección mucho más difícil de desaprender que empezar desde cero.

Solución. Cadencia: cada dos sprints, 60 minutos, sin excepciones. Formato: cuatro columnas (conservado, eliminado, haciendo más de, bloqueado en). Cada acción tiene un nombre de dueño y una fecha. Rastree las acciones en un tablero público. Abra el siguiente retro revisando las acciones previas. Si menos del 70% están cerradas, esa es la conversación, y se salta la lluvia de ideas. El equipo objetará la primera vez. Hágalo de todos modos. A los dos ciclos, empezarán a llegar con acciones ya nombradas, porque saben que usted verificará.

Error 7: Contratar lento porque contratar es difícil

Síntoma. Tiene una vacante abierta desde hace cuatro meses. Ha entrevistado a ocho candidatos. Ninguno estaba "a la altura del estándar". Mientras tanto, su equipo ha estado al 80% de capacidad durante un trimestre y su senior más fuerte está haciendo el trabajo de dos personas y empieza a verse cansado en los 1:1.

Número real. Costo de una vacante senior abierta con compensación típica de SaaS: aproximadamente entre $20K y $30K al mes en producción perdida, más la carga que está poniendo en el resto del equipo, lo que aumenta su riesgo de rotación (ver Error 5). Una vacante abierta durante cuatro meses ha costado a la empresa $100K y probablemente le ha comprado una salida lamentable encima. El estándar que está manteniendo ahora ha costado más que lo que habrían costado combinadas dos contrataciones más económicas.

Solución. Defina el estándar por escrito: tres requisitos indispensables, tres deseables. Evalúe cada proceso de entrevista contra ese documento, no contra sensaciones. Si ha rechazado a cinco candidatos consecutivos, el estándar es el problema, no el mercado. Bájelo deliberadamente y dígale a su skip-level por qué, o divida el rol en dos contrataciones más económicas que puedan crecer hasta convertirse en una fuerte. La descripción del puesto de Staff Software Engineer complementaria es un buen punto de partida para tener el "estándar" escrito. Deje de esperar a un candidato perfectamente imposible mientras su equipo se agota. Ese candidato no va a llegar, y el equipo es el activo que realmente tiene.

Juntando todo: una autoauditoría de 30 minutos

Ponga un temporizador. Para cada uno de los siete errores anteriores, puntúese del 1 al 5. Sea honesto. Su skip-level ya lo sabe.

Cualquier cosa de 3 o menos: elija una solución de esta guía, prográmela en su calendario para esta semana y dígale a un compañero gerente de ingeniería a qué se comprometió para no poder dejarlo caer silenciosamente. No intente corregir los siete a la vez. Rebotará en todos ellos. Elija la puntuación más baja, aplique esa solución durante dos semanas y luego audite de nuevo.

La razón por la que esto funciona y "seré más intencional sobre el coaching" no funciona es que la solución es un bloque en el calendario, no una aspiración. Los bloques en el calendario sobreviven los lunes. Las aspiraciones no.

Qué tiene buen aspecto 90 días después

Imagen concreta. Si hizo la auditoría esta semana y se comprometió a una solución cada dos semanas, aquí está el equipo que debería tener para agosto:

• Entrega código menos del 10% de su semana y no se siente culpable al respecto.
• Ha tenido al menos dos 1:1 difíciles y el equipo está mejor por ellos, no peor.
• Su reporte semanal empieza con frecuencia de despliegue y tasa de fallos en cambios, no story points.
• Cada subordinado directo sabe cómo es el siguiente nivel para él, en papel, y ha tenido al menos una conversación con usted sobre dónde está en relación con eso.
• El equipo recibe contexto por defecto compartido, no por defecto protegido, y su standup de contexto semanal es un hábito que nadie cuestiona.
• Los retros funcionan en una cadencia de dos sprints con un registro de acciones cerrado que está por encima del 70% a tiempo.
• Ninguna vacante ha estado abierta más de ocho semanas sin una recalibración del estándar escrita.

Nada de esto requiere un trasplante de personalidad. Requiere decidir que la versión de usted que tolera estos patrones es la que su equipo está pagando, y luego hacer un cambio a la vez hasta que no lo estén.

Aprenda más

• Los primeros 30/60/90 días como nuevo gerente de ingeniería
• Cómo conducir 1:1s con ingenieros que impulsan el cambio
• Métricas del gerente de ingeniería: velocidad de entrega, calidad, retención de personal y contratación
• Conversaciones sobre ascenso y desempeño
• Descripción del puesto de Staff Software Engineer