Métricas del gerente de ingeniería: velocidad de entrega, calidad, retención de personal y contratación

La primera vez que entré a un QBR con un gráfico de story points, mi VP me dejó hablar unos noventa segundos antes de decir: "Camellia, ¿cuál es tu rotación lamentable? ¿Y tu frecuencia de despliegue? Olvida los puntos."

No tenía ninguno de los dos números. Tenía un gráfico de barras bellamente coloreado de velocidad de entrega por sprint y una diapositiva titulada "Rendimiento del T3 +18%". Nada de eso sobrevivió el contacto con la pregunta. No estaba siendo grosero. Estaba siendo honesto. El nivel ejecutivo financiaba resultados. Yo había llevado actividad. No estábamos hablando el mismo idioma, y la conversación de presupuesto que siguió fue tan cálida como cabría esperar.

Esa reunión cambió la forma en que gestiono los dashboards. Esta guía es el dashboard que ojalá hubiera tenido: seis métricas, rangos de números reales, diagnósticos nombrados, una diapositiva de QBR. Nada más, porque más es cómo la ley de Goodhart se lo come.

Por qué los resultados superan al rendimiento

Las métricas de rendimiento (story points, tickets cerrados, líneas de código, horas registradas) miden actividad. La actividad es lo que hizo su equipo. Los resultados son lo que obtuvo la empresa. El nivel ejecutivo financia resultados: velocidad de entrega, fiabilidad, durabilidad del equipo, rendimiento de la contratación. Si no puede traducir el trabajo de su equipo a esos cuatro cubos, lo sacarán de las conversaciones de plantilla, y no lo verá venir hasta que el aviso de congelamiento de ofertas llegue a su bandeja de entrada.

Hay una segunda razón. Las métricas de rendimiento son fáciles de manipular sin que nadie lo pretenda. Dígale a un equipo que mide tickets cerrados y en un trimestre tendrá tickets más pequeños. Dígale que mide story points y en dos trimestres tendrá inflación que haría ruborizar a un banquero central. Las métricas de resultados son más difíciles de manipular porque están vinculadas a la realidad. El deploy o ocurrió o no, el ingeniero o se quedó o se fue, la oferta fue aceptada o rechazada.

Entonces: seis métricas. Cuatro para entrega y fiabilidad, dos para salud del equipo. Ese es el conjunto.

Frecuencia de despliegue

¿Con qué frecuencia llega el código de su equipo a producción? Diariamente, semanalmente, mensualmente o menos. Esta es la primera métrica DORA y la señal más clara de si su canal de entrega es realmente un canal o una serie de puertas cerradas con llaves manuales.

Nivel objetivo según la madurez del equipo:

La mayoría de los equipos de producto deberían situarse en Alto. Si está en Medio y el trabajo lo justifica (industria regulada, ciclos de QA largos), díganlo en la diapositiva. Si está en Bajo y es un equipo SaaS, eso es un hallazgo, no un número.

Tiempo de entrega de cambios

Tiempo desde el commit hasta producción. Esta es la segunda métrica DORA y la que le dice dónde vive realmente el cuello de botella. Horas, días o semanas.

Cuando mide esto y lo desglosa, generalmente encuentra uno de tres culpables: revisión de código (el PR lleva dos días abierto esperando a un senior que está en reuniones), CI (el conjunto de pruebas tarda 47 minutos y falla una de cada cinco veces), o puerta de deploy (aprobación manual que vive en el calendario de alguien). Elija el más largo y corríjalo. No intente corregir los tres a la vez.

Rangos saludables por tipo de equipo:

• Equipo de producto, aplicación web: menos de 24 horas, idealmente menos de 8.
• Equipo de plataforma, infraestructura: menos de 48 horas.
• Equipo mobile: 3 a 7 días, limitado por la revisión de la tienda de aplicaciones.

Si su tiempo de entrega es de dos semanas y su frecuencia de despliegue es diaria, algo está matemáticamente desajustado. O está haciendo deploy principalmente de cambios triviales mientras los grandes se pudren, o está contando mal. Investigue antes de poner la diapositiva.

Tasa de fallos en cambios

Porcentaje de deploys que provocan un rollback, un hotfix o un incidente en producción. La tercera métrica DORA. La banda objetivo es del 0 al 15%, con equipos saludables situados entre el 5 y el 10%.

Dos cosas a vigilar. Primero, una tasa de fallos en cambios de cero es una señal de alerta, no un logro. Generalmente significa que su equipo está sometiendo el código a exceso de pruebas, haciendo deploy demasiado raramente o contando insuficientemente los incidentes. Segundo, esta métrica tiene un suelo natural. El software es difícil, los humanos cometen errores y una tasa del 2% es ruido, no una señal de declive. No persiga el último punto porcentual a costa de la velocidad de entrega.

Cuando la tasa de fallos en cambios supera el 15%, el diagnóstico es casi siempre uno de estos: cobertura de pruebas insuficiente en rutas críticas, un proceso de lanzamiento que agrupa demasiado (de modo que los fallos se enredan), o nuevas incorporaciones que hacen deploy a producción antes de que comprendan el radio de impacto. Nómbrelo. No lo promede en algo genérico.

MTTR

Tiempo medio de restauración. Cuando algo se rompe en producción, ¿cuánto tiempo pasa hasta que vuelve a funcionar? Horas, no días. Esta es la cuarta métrica DORA y la más vinculada a la higiene on-call.

Un buen MTTR es inferior a 4 horas para un producto SaaS. Inferior a 1 hora para equipos de élite. El truco es que el MTTR no tiene que ver realmente con la rapidez con la que puede escribir una corrección. Tiene que ver con la rapidez con la que puede detectar, diagnosticar y hacer deploy. La mayor parte del MTTR lento que he depurado provenía de uno de tres lugares: alertas que no se dispararon (de modo que el equipo se enteró de la interrupción por un cliente), runbooks que no existían (de modo que el ingeniero on-call lo descubría desde cero), o un canal de deploy que tarda 90 minutos (de modo que incluso después de escribir la corrección, espera).

Si el MTTR está aumentando, revise la carga on-call. Los ingenieros on-call agotados son ingenieros on-call lentos. Esta es la métrica donde la frecuencia de despliegue, la tasa de fallos en cambios y la salud del equipo se tocan.

Rotación lamentable de 12 meses

La primera de las dos métricas de salud del equipo, y la que más le importa a su VP.

La rotación lamentable cuenta solo a las personas que quería conservar. Si se va un bajo rendidor, eso no es lamentable. Si se va un ingeniero estable de nivel medio que nunca hizo olas y usted se encoge de hombros, eso no es lamentable. Si se va un IC senior, un tech lead o un junior de alta trayectoria, eso es lamentable. Sea honesto consigo mismo cuando lo etiquete. Los managers tienden a decidir retroactivamente que todos los que se fueron "no eran el perfil adecuado", que es como termina con el 0% de rotación lamentable y un equipo que está a medio irse.

Líneas base de la industria tecnológica para 2026:

• Saludable: 8 a 12% anual.
• Zona de vigilancia: 13 a 15%.
• Alerta: por encima del 15%.
• Alerta máxima: por encima del 20%.

Rastréelo en una base de 12 meses continua, no por trimestre calendario. Los números trimestrales son demasiado ruidosos en equipos pequeños. Si tiene ocho ingenieros y una salida lamentable en el segundo trimestre, eso es el 12.5%: bien en términos continuos, aterrador en un gráfico trimestral.

Tasa de aceptación de ofertas más tiempo de incorporación

La segunda métrica de salud del equipo, y la que le dice si su equipo puede crecer.

Dos submétricas, una fila en la diapositiva. Tasa de aceptación de ofertas: de las ofertas que extendió el último trimestre, ¿qué porcentaje fue aceptado? El objetivo es el 70% o más. Por debajo del 60% significa que sus ofertas no son competitivas (generalmente en compensación, a veces en título, ocasionalmente en la historia que cuenta).

Tiempo de incorporación: desde la fecha de inicio hasta el primer PR no trivial fusionado a producción, ¿cuántos días? El objetivo es menos de 30. Si su nuevo empleado promedio tarda 60 días en entregar algo real, su incorporación está rota o su codebase es un laberinto. De cualquier manera, eso es un hallazgo.

Ambos números juntos cuentan la historia de contratación. Alta tasa de aceptación, incorporación rápida: el motor de contratación funciona. Alta tasa de aceptación, incorporación lenta: usted vende bien, usted incorpora mal. Baja tasa de aceptación, incorporación rápida: cuando la gente sí se une, prospera, pero no puede cerrar. Baja tasa de aceptación, incorporación lenta: el motor está roto en ambos extremos.

NPS de ingeniería

Encuesta de pulso trimestral, una pregunta: "¿Recomendaría este equipo a otro ingeniero?" Escala de cero a diez. Reste los detractores (0 a 6) de los promotores (9 a 10), ignore los pasivos (7 a 8). El resultado está entre -100 y +100.

Los equipos de ingeniería saludables puntúan entre 30 y 50. Por encima de 50 es excelente. Por debajo de 20 es una advertencia. Negativo es un incendio que ya ha comenzado; simplemente aún no ha visto el humo.

Hágalo la misma semana cada trimestre. Anónimo. Siempre incluya una pregunta de seguimiento abierta: "¿Qué es lo único que haría subir su puntuación un punto?" Lea cada respuesta. El número es el titular; los comentarios son el diagnóstico.

El diagnóstico de "alta velocidad de entrega pero alta rotación"

Aquí está el arquetipo que sorprende a la mayoría de los gerentes de ingeniería. La frecuencia de despliegue es alta. La tasa de fallos en cambios es baja. El tiempo de entrega es excelente. El MTTR es sólido. Por las cuatro métricas DORA, el equipo está entregando como un campeón.

Y la rotación lamentable está aumentando. El NPS de ingeniería está bajando. Las personas que quería conservar se están yendo.

El equipo está entregando su salida de la empresa.

Viví esto exactamente una vez. Hacíamos 60 deploys al mes, tasa de fallos en cambios del 4%, MTTR de menos de 90 minutos, y perdí tres ingenieros en un trimestre, dos de ellos seniors. El dashboard de métricas mentía por omisión. La verdad apareció en las entrevistas de salida: "Estoy agotado." "No he crecido en 18 meses." "Mi amigo en una empresa de la competencia gana un 30% más por el mismo trabajo."

Generalmente hay tres causas, y a menudo se acumulan:

1. Agotamiento. La alta velocidad de entrega es sostenible durante un trimestre, a veces dos. Pasado ese punto, está pidiendo prestado contra el futuro del equipo.
2. Brecha salarial. El mercado se movió, sus bandas no, y sus seniors lo saben porque reciben mensajes de LinkedIn todos los martes.
3. Sin trayectoria de crecimiento. Las personas se quedaron cuando estaban aprendiendo. Una vez que el codebase les resultó pequeño, buscaron uno más grande.

Nombre la causa en la diapositiva. No la promede en un genérico "la gente se va, trabajaremos en el compromiso". Esa frase nunca ha salvado a un equipo.

Métricas de vanidad que debe dejar de reportar

La ley de Goodhart: cuando una medida se convierte en un objetivo, deja de ser una buena medida. Cada métrica de esta lista, incluidas las seis anteriores, es vulnerable. Pero estas cuatro son suficientemente vulnerables como para que deba retirarlas por completo:

• Story points completados. La inflación está garantizada. Genera historias más pequeñas enmarcadas como más grandes. No le dice nada sobre lo que llegó a producción.
• Tickets cerrados. El mismo problema, un marcador diferente. Anima a los tickets a multiplicarse.
• Líneas de código. Una medida de escritura, no de ingeniería. Penaliza las eliminaciones, que suelen ser los mejores PR.
• Horas registradas. Mide presencia, no producción. Penaliza a los padres y premia los mensajes de Slack performativos a altas horas de la noche.

Cámbielos. Los story points y los tickets se convierten en frecuencia de despliegue y tiempo de entrega. Las líneas de código se convierten en tasa de fallos en cambios. Las horas registradas se convierten en NPS de ingeniería, porque si su equipo está sano y entregando, no necesita contar horas.

La diapositiva del QBR

Una diapositiva, seis filas de métricas, tres columnas: actual, objetivo, flecha de tendencia. Agregue una oración de diagnóstico por fila. Ese es el formato.

Esquema de ejemplo:

Seis filas. Seis diagnósticos. Sin story points. Sin gráfico de velocidad de entrega oculto en un apéndice. Si un número es malo, dígalo claramente y nombre lo que está haciendo al respecto. Los VP confían en los gerentes de ingeniería que nombran los problemas más rápido de lo que el VP los habría detectado. Desconfían de los gerentes de ingeniería que los ocultan.

Qué pedirle a su VP

Cierre el QBR con una pregunta, no con una vuelta de honor. Pregunte cuáles dos de las seis métricas importan más para la empresa este trimestre y qué banda objetivo se consideraría un éxito.

Intentar optimizar las seis a la vez es cómo no logra nada. Un equipo que trabaja en la velocidad de entrega no está también trabajando en el rendimiento de la contratación, y un equipo que trabaja en la contratación va a sufrir un golpe temporal en el tiempo de entrega mientras los seniors entrevistan candidatos en lugar de revisar PR. Elija dos. Alinee los objetivos. Repita la pregunta el próximo trimestre.

Si su VP dice "las seis", empuje suavemente hacia atrás. Diga: "Si tuviera que invertir menos en dos de ellas este trimestre para invertir completamente en las otras dos, ¿en cuáles desinvertiría?" Esa pregunta casi siempre obtiene una respuesta real, porque fuerza una concesión a la superficie.

Esta es la versión del QBR con la que debería haber entrado la primera vez. Seis métricas. Números reales. Diagnósticos nombrados. Una diapositiva. El gráfico de story points se queda en el cajón donde le corresponde.

Aprenda más

• La cadencia de 1:1 que realmente funciona
• Cómo gestionar una rotación on-call sin agotar al equipo
• Evaluaciones de desempeño para ingenieros sin el teatro
• Cómo contratar ingenieros senior en un mercado competitivo
• JD complementario: Staff Software Engineer