Mides incidentes, pero ignoras las métricas que importan (y por eso tu equipo no mejora)

El 69% de equipos miden número de incidentes. Solo el 12% usa métricas custom que realmente predicen problemas. Resultado: sabes cuándo fallas, pero no por qué ni cómo evitarlo.

El dato que debería preocuparte

LeadDev acaba de publicar su Engineering Performance Report 2025 con datos de 400 líderes técnicos. Una pregunta destroza el autoengaño colectivo de la industria:

"¿Qué métricas usa tu equipo para medir performance de sistemas?"

Las respuestas:

• 69%: Número de incidentes
• 60%: Severidad de incidentes
• 51%: Cumplimiento de SLAs
• 46%: Uptime
• 44%: Costes operacionales
• 12%: Métricas custom

Traducción: 7 de cada 10 equipos miden cuántas veces se cae el sistema. Solo 1 de cada 10 mide lo que realmente predice si se va a caer.

Si tu dashboard principal es un contador de incidentes, no estás midiendo performance. Estás midiendo fracasos.

Por qué esto es un problema (más gordo de lo que parece)

1. Las métricas reactivas no previenen problemas

Medir incidentes es como medir accidentes de coche para mejorar la conducción. Te dice que chocaste, no por qué ni cómo evitarlo.

El ciclo vicioso:

1. Incidente ocurre → contador sube
2. Post-mortem → "necesitamos más monitoring"
3. Añades más dashboards de... incidentes
4. Siguiente incidente → repetir

Resultado: Más datos del pasado, cero capacidad de prevenir el futuro.

2. Ignoras las métricas que sí predicen (y cuestan menos)

Según el mismo report, solo el 39% rastrea "engineering time" (tiempo del equipo en tareas).

Esto es crítico porque:

• Un equipo que invierte 60% de tiempo en "apagar fuegos" va a tener incidentes
• Un equipo que invierte 40% en deuda técnica va a reducir incidentes
• Pero si no mides tiempo, no sabes dónde lo gastas

Ejemplo real (cliente nuestro, fintech Series B):
Before: Medían solo incidentes (5-8/mes)
After: Añadieron tracking de tiempo del equipo → Descubrieron que 70% del tiempo iba a "parches urgentes" → Redujeron parches a 30%, aumentaron refactoring a 40% → Incidentes bajaron a 1-2/mes en 2 meses.

No necesitaban más monitoring de incidentes. Necesitaban medir dónde gastaban el tiempo.

3. La paradoja del uptime

46% de equipos miden uptime. Suena razonable, ¿no?

Problema: uptime es una métrica de resultado, no de causa.

Escenario típico:

• Tu sistema tiene 99.9% uptime (43 min downtime/mes)
• Crees que vas bien
• Pero ese 99.9% oculta que:
  • 80% del equipo está en "modo bombero"
  • Deploy tarda 6h por miedo a romper
  • Deuda técnica crece sin control

Uptime alto ≠ sistema sano. Puede ser un equipo exhausto sosteniendo un castillo de naipes.

Las métricas que SÍ predicen (y nadie mide)

Según el LeadDev Report, estas son las métricas menos rastreadas pero más predictivas:

1. Engineering time breakdown (39% lo mide)

Qué medir:

• % tiempo en nuevas features
• % tiempo en bugs/parches
• % tiempo en deuda técnica
• % tiempo en "apagar fuegos"

Por qué importa: Si >50% del tiempo es reactivo (bugs + fuegos), tu sistema está enfermo aunque el uptime sea 99.9%.

2. MTTD - Mean Time To Detect (23% lo mide)

Qué es: Tiempo entre que ocurre un problema y lo detectas.

Por qué importa: Un bug que tarda 3 días en detectarse causa 10x más daño que uno detectado en 10 minutos.

Benchmark: Good: <30 min MTTD para issues críticos | Excellent: <5 min MTTD (monitoring proactivo + alerts)

3. Deployment frequency + lead time

Por qué importa: Equipos que deployean 10x/día tienen 60% menos incidentes que equipos que deployean 1x/semana (DORA metrics).

Paradoja: Más deploys = menos incidentes (porque cambios pequeños son menos riesgosos).

4. Custom metrics (solo 12% las usa)

Qué son: Métricas específicas de tu dominio que predicen problemas.

Ejemplos:

• E-commerce: "Checkout abandonment rate"
• Fintech: "Failed transaction retry rate"
• SaaS: "API error rate per client"

La métrica invisible (que explica todas las demás): Carga cognitiva del equipo

Hay una métrica que casi nadie rastreja pero explica por qué las otras métricas fallan: la carga cognitiva del equipo.

¿Qué es carga cognitiva en equipos de desarrollo?

Definición: La cantidad de información que un developer debe mantener en su cabeza para ser productivo.

Los 3 tipos de carga cognitiva (según Team Topologies):

1. Carga intrínseca: Complejidad inherente de la tarea
2. Carga extrínseca: Ruido del entorno (herramientas mal configuradas, deploys manuales)
3. Carga pertinente: Aprendizaje útil que queda

Cómo medir carga cognitiva (sin encuestas complejas)

✅ Context switches por día:

• <3 cambios/día = carga manejable
• 5-7 cambios/día = carga alta (productividad -60%)
• >10 cambios/día = equipo colapsado

Cómo medir: Track Jira/Linear tasks por developer por día + reuniones en calendario.

✅ Time to productive (nuevo developer):

• <2 semanas = arquitectura simple, buena documentación
• 4-6 semanas = complejidad media
• >8 semanas = carga cognitiva brutal

✅ Tool proliferation:

• <5 herramientas = bien
• >10 herramientas = carga extrínseca brutal

La conexión oculta: Carga cognitiva → Incidentes

Por qué equipos con alta carga cognitiva tienen más incidentes:

1. Developer exhausto comete errores: Carga cognitiva >80% → 3x más bugs introducidos
2. Zero tiempo para prevención: Si 70% del tiempo es firefighting, no hay espacio mental para refactoring
3. Pérdida de contexto: Cambiar de contexto 7x/día → olvidas edge cases, skippeas tests

DevEx: La métrica que unifica todas las demás

Developer Experience (DevEx) no es "tener Slack bonito". Es medir fricción en el trabajo diario del developer.

Las 3 dimensiones de DevEx (según SPACE framework):

1. Feedback loops: ¿Cuánto tarda un developer en validar su cambio?
   • Build time: <5 min = excelente, >15 min = fricción alta
2. Flow state: ¿Cuántas horas de trabajo profundo sin interrupciones?
   • <2h/día = equipo reactivo (carga cognitiva brutal)
   • 4-6h/día = equipo sano
3. Cognitive load: ¿Cuánta complejidad innecesaria carga el developer?

Alta carga cognitiva
  → Developer exhausto
    → Más bugs introducidos
      → Más incidentes
        → Más firefighting
          → Menos tiempo para refactoring
            → Deuda técnica crece
              → Deploy más arriesgado
                → Más carga cognitiva
                  → [ciclo se repite]
          

Framework: Qué métricas rastrear (y en qué orden)

Nivel 1: Básico (si no tienes esto, empieza aquí)

• Uptime / downtime
• Número y severidad de incidentes
• MTTR (mean time to resolve)

Problema: Solo mides fracasos, no prevención.

Nivel 2: Intermedio (aquí mejoras de verdad)

• MTTD (mean time to detect)
• Engineering time breakdown
• Deployment frequency + lead time
• Operational costs por servicio

Beneficio: Empiezas a ver patrones ANTES de incidentes.

Nivel 3: Avanzado (aquí compites con top performers)

• Métricas custom de tu dominio
• Cost per feature
• % code coverage + mutation testing
• Change failure rate
• Context switches por developer (carga cognitiva)
• Feedback loop time (DevEx)
• Flow state hours (tiempo de trabajo profundo)

Beneficio: Predices problemas con semanas de antelación y mides salud del equipo, no solo del sistema.

Caso real: De apagar fuegos a 0 incidentes en 8 semanas

Cliente: Scaleup healthtech Series B, 15 developers
Problema: 6-8 incidentes/mes, equipo exhausto

Fase 1: Diagnóstico (Semana 1-2)

• Implementamos tracking engineering time
• Descubrimiento: 65% tiempo en hotfixes y parches
• Root cause: No medían MTTD ni deployment frequency

Fase 2: Métricas predictivas (Semana 3-4)

• Añadimos MTTD tracking: 4 horas promedio (malo)
• Añadimos deployment frequency: 2x/semana (bajo)
• Añadimos custom metric: "API timeout rate per endpoint"

Fase 3: Acción (Semana 5-8)

• Priorizaron reducir MTTD a <30 min (mejor alerting)
• Aumentaron deploys a 2x/día (CI/CD refactor)
• Monitorearon API timeout → detectaron 3 endpoints problemáticos antes de incidentes

Resultados (2 meses después):
• Incidentes: 6-8/mes → 0-1/mes (-87%)
• MTTD: 4h → 15 min (-93%)
• Time en hotfixes: 65% → 20% (-70%)
• Context switches: 8/día → 4/día (-50%)
• Flow state: 1.5h/día → 5h/día (+233%)

Inversión: 40h equipo + €200/mes tooling
ROI: ~120h/mes ahorradas = €12k/mes

"Finalmente trabajamos en features, no en fuegos"

Insight clave: Reducir context switches fue el cambio que permitió todo lo demás. Con más flow state, detectaron problemas antes, escribieron mejor código, redujeron bugs.

Acción inmediata: Qué hacer esta semana

Lunes (1h): Audita tus métricas actuales

Pregunta honesta: ¿Qué % de tus métricas son reactivas (incidentes) vs predictivas (MTTD, time breakdown, custom)?

Si >70% son reactivas, estás en modo bombero.

Martes (2h): Añade 1 métrica predictiva

Elige una:

• Engineering time breakdown (más fácil de empezar)
• MTTD (más impacto si tienes incidentes frecuentes)
• Deployment frequency (más impacto si deploys son dolorosos)

Miércoles-Viernes (3h): Primer análisis

• Trackea métrica durante 1 semana
• Analiza primeros datos
• Identifica 1 quick win

Conclusión: Deja de contar fracasos, empieza a predecir éxitos

El problema de medir solo incidentes:

• Sabes que fallaste
• No sabes por qué
• No puedes evitar el próximo

La solución:

• Mide tiempo del equipo (para saber si estás en modo reactivo)
• Mide MTTD (para detectar problemas antes de que escalen)
• Mide métricas custom de tu dominio (para predecir problemas con días de antelación)
• Mide carga cognitiva y DevEx (para entender la salud real de tu equipo)

El cambio de mentalidad: De "¿cuántos incidentes tuvimos?" a "¿cuántos incidentes evitamos?"