Lo que ya sospechábamos sobre las métricas: A veces medir bien es hacerlo mal

Igual te suena esto que te voy a contar.

Un CTO llega a consulta preocupado porque «los números están bien pero todo va mal». El equipo cumple los objetivos del trimestre, los dashboards se ven verdes, pero el producto está lleno de bugs, la deuda técnica es una bomba de relojería y la gente buena se está yendo.

¿Te suena?

Lo curioso es que esto no pasa porque la gente sea mala o incompetente. Ni siquiera porque los objetivos estén mal planteados (bueno, a veces sí). El problema real está en el diseño del sistema de evaluación.

Hace poco leí «Lo que la IA puede enseñarnos sobre el diseño de mejores KPI» de Balázs Kovács, y tuve uno de esos momentos de «j*der, esto explica perfectamente lo que muchas veces he visto». Resulta que los investigadores de machine learning llevan años lidiando con este mismo problema: cómo evitar que un sistema optimice la métrica equivocada.

La diferencia es que ellos lo llaman «overfitting». Nosotros lo llamamos «trabajar para la demo».

La Ley de Goodhart nos dice por qué tu equipo está jugando al Tetris con los KPI

La ley de Goodhart dice algo muy simple: Cuando una medida se convierte en un objetivo, deja de ser una buena medida.

Wells Fargo lo aprendió por las malas cuando sus objetivos de ventas acabaron provocando fraude masivo. En ingeniería no se suele llegar a titular de periódico, pero el problema es el mismo:

El patrón es siempre el mismo. La métrica deja de ser una señal de valor y pasa a ser el objetivo. Y la gente, que no es tonta, optimiza lo que le van a medir. Aunque sea una estupidez.

Lo que los algoritmos nos enseñan sobre gestionar Personas (Sí, en serio)

En machine learning hay un problema clásico llamado overfitting. Un modelo aprende tan bien los datos de entrenamiento que cuando se enfrenta al mundo real, la caga completamente. Ha memorizado patrones irrelevantes en lugar de aprender lo importante.

¿Te recuerda a algo?

Datos de entrenamiento = tus métricas internas bonitas
Mundo real = clientes cabreados, producto que no funciona, equipo quemado
Overfitting = «vamos bien en los KPI» mientras Roma arde

Los investigadores de IA han desarrollado estrategias para evitar esto. Y resulta que funcionan sorprendentemente bien para diseñar evaluaciones de desempeño que no jodan a tu equipo.

1. Saber cuándo dejar de optimizar (Early Stopping para humanos)

En IA se llama «early stopping»: llega un punto donde seguir optimizando una métrica empeora el resultado real. Se para el entrenamiento antes de llegar ahí.

En ingeniería casi nunca hacemos esto.

Recuerdo un cliente que llevaba tres años optimizando «tiempo de despliegue». Cada trimestre mejoraban. El problema es que en el producto tno cabían más bugs. Nadie se había parado a preguntar: «oye, ¿esto sigue siendo bueno para nosotros?»

Intel pasó por esto. Optimizaron velocidad de reloj durante años hasta que descubrieron que estaban empeorando el consumo energético y el rendimiento real. Les costó años y millones corregirlo.

Qué hacer en tu equipo:

Pregúntate cada trimestre: «¿esta métrica sigue siendo útil o nos está jodiendo?»

Si una métrica genera comportamientos raros, cámbiala. No es ciencia espacial.

Define umbrales mínimos en vez de «cuanto más mejor». Ejemplo: en lugar de «máximos despliegues posibles», define «mínimo X estabilidad» y luego enfoca en aprendizaje o innovación.

2. Introducir Variabilidad para que no te la cuelen

Los modelos de IA se vuelven frágiles cuando todo es predecible. Por eso los investigadores introducen ruido deliberado: datos ligeramente distintos, conexiones que se apagan al azar, validaciones sorpresa.

En organizaciones pasa igual. Si todo es predecible, la gente aprende a hacer trampa (aunque la trampa sea legal).

Hemos visto equipos que solo trabajaban para la demo. Código limpio justo antes de la revisión. Optimización de lo visible, ignorancia de lo importante.

Estrategias prácticas:

• Code reviews o auditorías técnicas aleatorias (no anunciadas)
• Rotación de reviewers para que la gente no aprenda «cómo le gusta el código a Pepe»
• Evalúa conversaciones con clientes, no solo entregas. Pregunta: «¿habló esta semana con usuarios?»
• El objetivo no es pillar a nadie. Es alinear el comportamiento con el valor real, incluso cuando nadie está mirando.

3. No compliques la métrica más de lo que puedes gestionar

Un modelo complejo con pocos datos es un desastre. En organizaciones también.

El error clásico es diseñar sistemas de evaluación súper sofisticados que nadie entiende. Fórmulas misteriosas, scores opacos, métricas compuestas que requieren un doctorado para interpretarlas.

WeWork y el caso de JPMorgan con su trader de Londres (perdieron 6.000 millones porque las métricas eran tan complejas que ocultaron el desastre). Aprendieron esto de la peor forma posible: la complejidad puede ocultar problemas hasta que es tarde.

La regla simple:

• Equipo junior o en formación → métricas básicas y robustas
• Equipo maduro → puedes añadir complejidad, pero tiene que estar explicada
• Si no puedes supervisar la complejidad, no la introduzcas

Las startups hacen esto bien sin querer: se centran en retención, fiabilidad, coste. Simple. Claro. Las grandes corporaciones deberían copiarles.

4. Poner límites para evitar que la gente haga tonterías.

En IA, la «regularización» penaliza la complejidad excesiva. En organizaciones, esto significa poner restricciones que hagan más difícil jugar al sistema que hacer bien el trabajo.

Amazon detecta patrones artificiales en valoraciones. Netflix dejó de optimizar solo «horas vistas» porque se dieron cuenta de que la gente veía cosas que odiaba.

En equipos técnicos:

• Combina métricas de velocidad con métricas de calidad (no una o la otra)
• Si los resultados son «demasiado buenos», activa revisiones adicionales
• Añade checks cualitativos obligatorios. Ejemplo: una conversación de 15 minutos sobre decisiones técnicas después de cada release
• Premia impacto sostenible, no solo corto plazo

El test de la distorsión métrica

Para saber si tu sistema de evaluación está roto, hazte estas preguntas:

• ¿La gente habla más de «cómo quedar bien en la métrica» que del problema real?
• ¿Las métricas mejoran mientras la calidad empeora?
• ¿Escuchas «pero cumplimos los objetivos» cuando algo sale mal?
• ¿Los equipos mejor puntuados no son los que generan más valor?

Si contestaste «sí» a alguna, tienes un problema de diseño de sistema.

El problema no es la gente, es el sistema (como decía Siniestro Total)

Las organizaciones son sistemas de optimización. La gente se comporta racionalmente dentro de esos sistemas.

Si un sistema produce comportamientos estúpidos, el problema no es la gente. Es el diseño del sistema.

Evaluar desempeño en ingeniería no debería ser «medir a las personas». Debería ser crear condiciones donde hacer un buen trabajo sea lo más fácil.

Concluión: Las métricas son vivas, no son un dogma

La principal lección de la IA es que la medición no es «define y olvida». Es una práctica viva. Requiere revisión, ajuste y, sobre todo, criterio humano.

No todo lo importante se puede medir. Pero lo que mides define el comportamiento.

Por eso diseñar bien los sistemas de evaluación no es un tema de HR. Es una responsabilidad crítica del liderazgo técnico.

Y sí, puedes tener métricas. Solo que más inteligentes.