⏱️ Lectura: 11 min
En 2001, dos investigadores del MIT publicaron un paper que todavía explica, con precisión incómoda, por qué tu equipo no logra mejorar: la trampa de capacidad. Nelson Repenning y John Sterman demostraron, con modelos de dinámica de sistemas, que las organizaciones que más necesitan mejorar suelen ser justamente las que menos tiempo tienen para hacerlo, y que esa falta de tiempo no es accidental: es el resultado predecible de cómo reaccionamos ante la presión.
📑 En este artículo
- TL;DR
- La paradoja de la mejora de procesos
- Trabajar más frente a trabajar mejor: los dos lazos
- El ciclo vicioso de la trampa de capacidad
- Nadie recibe crédito por los incendios que nunca ocurrieron
- Qué significa para los equipos de software en 2026
- Cómo salir de la trampa
- Preguntas frecuentes
- ¿Qué es exactamente la trampa de capacidad?
- ¿Quiénes escribieron el paper y cuándo?
- ¿Por qué el título habla de crédito y problemas que nunca ocurrieron?
- ¿Cómo se relaciona con la deuda técnica en software?
- ¿Por qué dos equipos iguales terminan en resultados opuestos?
- ¿Cuál es la salida según los autores?
- Referencias
El título original lo resume todo: Nobody Ever Gets Credit for Fixing Problems That Never Happened. Veinticinco años después, en plena era de DevOps, deuda técnica y guardias de on-call, el diagnóstico está más vigente que nunca.
TL;DR
- Nelson Repenning y John Sterman (MIT) publicaron ‘Nobody Ever Gets Credit for Fixing Problems That Never Happened’ en California Management Review, verano de 2001.
- El paper modela con dinámica de sistemas por qué la mayoría de los programas de mejora fracasan pese a usar herramientas probadas como TQM o Six Sigma.
- Distingue dos respuestas a la presión: ‘trabajar más’ (efecto rápido pero temporal) y ‘trabajar mejor’ (lento pero acumulativo).
- Bajo presión, los equipos recortan el tiempo de mejora; la capacidad baja, aparecen más errores y la presión crece: un lazo reforzador.
- Es un sistema con punto de inflexión: diferencias mínimas al inicio llevan a resultados opuestos y autoconfirmados.
- Apagar incendios es visible y se premia; la prevención es invisible, así que los gerentes atribuyen mal la causa del problema.
- El diagnóstico aplica directo a la deuda técnica, el ciclo de incidentes y el on-call en equipos de software de 2026.
La paradoja de la mejora de procesos
Durante las décadas de 1980 y 1990, las empresas invirtieron fortunas en metodologías de mejora: gestión de calidad total (TQM), reingeniería, justo a tiempo, Six Sigma. Las herramientas funcionaban en el papel y había casos de éxito espectaculares. Sin embargo, las encuestas que cita el propio paper reportaban que cerca de dos tercios de estos programas no lograban sostener sus resultados en el tiempo. Las mismas técnicas que transformaban a una planta dejaban a otra peor que antes. Esa contradicción es lo que Repenning y Sterman llamaron la paradoja de la mejora.
Su explicación rompe con la intuición habitual. No fracasan por elegir la herramienta equivocada ni por falta de compromiso de la dirección. Fracasan porque la mejora de procesos es un sistema dinámico con retroalimentación, y los sistemas con retroalimentación se comportan de formas que la lógica lineal no anticipa. La trampa de capacidad es el nombre del estado en el que una organización queda atrapada: tan ocupada lidiando con los problemas de hoy que nunca invierte en evitar los de mañana.
Trabajar más frente a trabajar mejor: los dos lazos
El corazón del modelo son dos maneras de cerrar la brecha entre el trabajo que hay que hacer y la capacidad disponible para hacerlo. La primera es trabajar más: extender horas, saltarse pasos, posponer el mantenimiento. Es un lazo de balance que da resultados inmediatos, pero su efecto es temporal y tiene costos ocultos: el cansancio, los atajos y la fatiga generan más defectos que vuelven como retrabajo.
La segunda es trabajar mejor: invertir tiempo en mejorar el proceso mismo, automatizar, documentar, reducir la fuente de los errores. Es un lazo reforzador: cada hora invertida hoy en capacidad reduce el trabajo de mañana, lo que libera más tiempo para seguir mejorando. El problema es su demora. La inversión en capacidad tarda en rendir, mientras que trabajar más alivia la presión ahora mismo. Cuando alguien está contra el reloj, casi siempre elige el alivio inmediato.
💭 Clave: trabajar más y trabajar mejor compiten por el mismo recurso escaso: el tiempo. Cada hora que dedicás a apagar el incendio de hoy es una hora que no dedicás a evitar el de mañana.
El ciclo vicioso de la trampa de capacidad
Acá es donde el modelo se vuelve peligroso. Supongamos que un equipo cede a la presión y recorta el tiempo de mejora para entregar más rápido. La capacidad del proceso —su habilidad para producir sin errores— empieza a depreciarse, igual que una máquina sin mantenimiento. Con menos capacidad aparecen más defectos, más incidentes y más retrabajo. Y ese retrabajo aumenta la carga, lo que incrementa la presión del próximo ciclo, lo que justifica recortar todavía más el tiempo de mejora. El sistema se hunde en espiral.
graph LR
A["Presión por entregar"] --> B["Menos tiempo para mejorar"]
B --> C["Capacidad del proceso baja"]
C --> D["Más errores e incendios"]
D --> ALo crucial es que el mismo lazo funciona en sentido inverso. Si el equipo logra proteger su tiempo de mejora, la capacidad sube, los errores caen, se libera tiempo y la mejora se acelera sola. Es decir, el sistema tiene dos equilibrios estables: uno virtuoso, donde mejorar es cada vez más fácil, y uno vicioso, donde apagar incendios consume todo. En el medio hay un punto de inflexión: dos equipos casi idénticos, separados por una diferencia mínima en sus condiciones iniciales, pueden terminar en extremos opuestos. Esto explica por qué la misma metodología salva a una organización y entierra a otra.
Podemos verlo con una asignación de tiempo simplificada por ciclo:
# Asignación de tiempo bajo presión (modelo simplificado)
tiempo_total = 100
tiempo_mejora = max(0, tiempo_total - trabajo_urgente)
capacidad += tiempo_mejora * tasa_aprendizaje
capacidad -= depreciacion
# Si trabajo_urgente sube, tiempo_mejora cae.
# La capacidad baja, generando MAS trabajo_urgente
# en el siguiente ciclo. El lazo se refuerza solo.
Nadie recibe crédito por los incendios que nunca ocurrieron
El segundo gran aporte del paper es psicológico, y le da su título. En la trampa de capacidad, apagar incendios es heroico y visible: el ingeniero que se queda toda la noche resolviendo un outage en producción recibe aplausos, bonos y ascensos. En cambio, quien dedicó tiempo a refactorizar un módulo, a escribir pruebas o a documentar un proceso —y por eso ese incidente nunca ocurrió— no recibe absolutamente nada. Su trabajo es, por definición, invisible: previno un problema que nadie llegó a ver.
Esa asimetría corrompe las atribuciones de la gerencia. Cuando los problemas se acumulan, el gerente concluye que la gente no se esfuerza lo suficiente y exige trabajar más, justo la respuesta que profundiza la trampa. Repenning y Sterman lo llaman una atribución autoconfirmada: como trabajar más alivia la presión a corto plazo, el gerente se convence de que tenía razón, y el ciclo de presión, recorte y deterioro se vuelve cultura. La organización empieza a premiar a los bomberos y a ignorar a los que construyen sistemas que no se incendian.
⚠️ Ojo: si tu organización celebra a quienes resuelven crisis pero ignora a quienes las previenen, está entrenando a todo el mundo para dejar que las crisis ocurran.
Qué significa para los equipos de software en 2026
El paper es de 2001 y habla de plantas industriales, pero cualquiera que haya trabajado en software reconoce la dinámica al instante. La trampa de capacidad es la teoría formal detrás de la deuda técnica. Cada vez que un equipo dice ‘ahora no hay tiempo para escribir pruebas’ o ‘lo arreglamos después del lanzamiento’, está recortando capacidad para aliviar la presión inmediata. La capacidad del sistema se deprecia: el código se vuelve frágil, los despliegues dan miedo, los incidentes se multiplican.
El on-call moderno es el caso de manual. Un equipo agotado por las alertas no tiene tiempo de arreglar las causas raíz de esas alertas, así que las alertas continúan, lo que mantiene al equipo agotado. La industria incluso le puso nombre a su antídoto en el SRE de Google: el presupuesto de error y el límite del 50% de trabajo operativo existen precisamente para impedir que la operación se coma toda la capacidad de mejora. Es la trampa de capacidad de Repenning y Sterman convertida en política explícita.
Lo mismo aplica a las migraciones eternas, a los frameworks que nadie actualiza y a los pipelines de CI inestables que todos toleran porque ‘arreglarlos lleva una semana que no tenemos’. En todos los casos, la lógica lineal —más urgencia, más esfuerzo— empuja al equipo hacia el equilibrio vicioso. La única salida es contraintuitiva: invertir en mejora justo cuando se siente que menos tiempo hay.
Cómo salir de la trampa
Repenning y Sterman no se quedan en el diagnóstico. La salida exige reconocer que el sistema es no lineal y que las soluciones intuitivas empeoran las cosas. Tres palancas concretas se desprenden del modelo:
- Proteger la capacidad de mejora — Reservar un porcentaje fijo del tiempo para trabajo de mejora y blindarlo de la presión de entregas, igual que el límite operativo del 50% de SRE. No es negociable ciclo a ciclo.
- Corregir las atribuciones — Hacer visible la prevención. Medir y reconocer el trabajo que evita incidentes, no solo el que los resuelve, para dejar de premiar el heroísmo de apagar incendios.
- Aceptar el valle — Salir de la trampa empeora las cosas a corto plazo: invertir en mejora reduce todavía más el tiempo disponible antes de que la capacidad se recupere. Si la dirección no tolera ese valle, vuelve a recortar y la espiral se reinicia.
La lección de fondo es que la mejora sostenida no es un problema de motivación ni de herramientas, sino de estructura. Mientras la estructura del sistema premie el alivio inmediato sobre la inversión a largo plazo, ninguna metodología —por buena que sea— va a sobrevivir el contacto con la presión real.
📖 Resumen en Telegram: Ver resumen
Preguntas frecuentes
¿Qué es exactamente la trampa de capacidad?
Es el estado en el que una organización dedica tanto tiempo a resolver los problemas urgentes de hoy que nunca invierte en mejorar el proceso que los genera. La capacidad se deprecia, aparecen más problemas y la presión aumenta, formando un lazo reforzador que se sostiene a sí mismo.
¿Quiénes escribieron el paper y cuándo?
Nelson Repenning y John Sterman, ambos del MIT, lo publicaron en la revista California Management Review en el verano de 2001 bajo el título ‘Nobody Ever Gets Credit for Fixing Problems That Never Happened’.
¿Por qué el título habla de crédito y problemas que nunca ocurrieron?
Porque el trabajo preventivo es invisible: si evitás un incidente, nadie lo nota. En cambio, apagar el incendio es heroico y se premia. Esa asimetría lleva a los gerentes a valorar el esfuerzo reactivo y a descuidar la inversión que evita los problemas.
¿Cómo se relaciona con la deuda técnica en software?
La deuda técnica es la trampa de capacidad aplicada al código. Recortar pruebas, documentación o refactorizaciones para entregar rápido deprecia la capacidad del sistema, lo que multiplica los incidentes y reduce todavía más el tiempo disponible para mejorar.
¿Por qué dos equipos iguales terminan en resultados opuestos?
Porque el sistema tiene un punto de inflexión entre dos equilibrios estables. Una diferencia mínima en las condiciones iniciales empuja a un equipo hacia el ciclo virtuoso y al otro hacia el vicioso, y cada equilibrio se refuerza a sí mismo.
¿Cuál es la salida según los autores?
Proteger un porcentaje fijo de la capacidad para trabajo de mejora, hacer visible y reconocer la prevención, y tolerar el empeoramiento de corto plazo que implica reinvertir antes de que la capacidad se recupere.
Referencias
- Repenning & Sterman, California Management Review (2001) — paper original ‘Nobody Ever Gets Credit for Fixing Problems That Never Happened’ (PDF en el MIT).
- Nelson P. Repenning — MIT Sloan — perfil del coautor, profesor distinguido de dinámica de sistemas y estudios organizacionales.
- John Sterman — Wikipedia — coautor y director del MIT System Dynamics Group.
- System dynamics — Wikipedia — fundamentos de stocks, flujos y lazos de retroalimentación usados en el modelo.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
0 Comentarios