Constraint Decay: por qué más proceso mata a tu equipo
Cada regla tiene un costo oculto. Constraint decay es cómo el exceso de proceso colapsa equipos —y agentes de IA—. Y la pregunta que lo arregla.
Tu equipo no es lento. Está enterrado bajo capas de proceso que nadie cuestionó. Cada metodología, cada reunión recurrente, cada checklist pareció razonable el día que se añadió —y por eso el exceso de proceso es tan difícil de ver—. Ninguna es el problema. El problema es la acumulación.
Lo llamo constraint decay. Una vez lo ves, no puedes dejar de verlo.
El problema: demasiado proceso, no demasiado poco
La mayoría de los equipos responden a la fricción añadiendo estructura. Un proceso para esto. Una convención para aquello. Una plantilla, un ritual, una aprobación. Cada regla nueva parece control.
No es gratis.
Cada regla que añades grava todas las decisiones futuras. Hay que recordarla, satisfacerla y reconciliarla con todas las que ya existen. Ese impuesto se paga en el recurso más escaso de un equipo: los ciclos de decisión. Al principio el costo es invisible. El sistema lo absorbe. La gente se adapta. El rendimiento aguanta.
Hasta que no.
El problema de fondo: la curva no es lineal
Esto es lo que hace peligroso al constraint decay. El rendimiento bajo restricciones acumuladas no baja en pendiente suave, dándote tiempo de reaccionar. Aguanta, aguanta, aguanta —y se desploma por un acantilado—.
Esa no-linealidad es por la que los buenos equipos se ven sorprendidos. Los cuadros de mando se ven bien hasta el trimestre en que todo se atasca. Nadie puede señalar la regla que lo provocó, porque ninguna regla sola lo hizo. Lo hizo el peso.
No es una observación nueva. Fred Brooks documentó una versión en 1975: añadir gente a un proyecto de software ya retrasado lo retrasa más, porque el costo de coordinación crece más rápido que el trabajo que debería absorber —lo que hoy llamamos Ley de Brooks—. El constraint decay es la misma física aplicada a reglas en lugar de a personas. El overhead de coordinación tiene muchas formas. La plantilla es solo la famosa.
El enfoque BBM: resta, no sumes
El instinto, cuando cae el rendimiento, es preguntar: ¿qué proceso nos falta?
Pregunta equivocada.
Pregunta mejor: ¿cuántas reglas puede perder este sistema antes de romperse? Ese simple replanteo le da la vuelta al ejercicio entero: de acumular a restar —la única dirección que de verdad recupera ciclos de decisión—. Es la misma disciplina que hay detrás de recortar tu stack de herramientas al hueso: el objetivo no es cero, es el conjunto mínimo que sigue entregando.
→ Inventaría cada regla, ritual y convención vigente. Todas, por escrito. → Para cada una, nombra el output concreto que produce. Si no produce ninguno, produce distracción. → Elimina lo que no pueda justificar su costo en ciclos de decisión. Por defecto, fuera. → Pon un techo al total. Un sistema tiene un presupuesto finito de reglas; gástalo a propósito.
El caso real: un colapso del ~60%
En 25 años construyendo y dirigiendo varios SaaS, he visto esto matar buenos equipos más de una vez.
Un equipo que vi de cerca añadió metodologías, reuniones, checklists y convenciones durante varios meses. Cada añadido era defendible en aislamiento. Ninguno era letal por sí solo. Al final, el output quedó en torno a un -60% por debajo de donde empezó. No colapsaron por falta de proceso. Colapsaron bajo su peso —justo la trampa del teatro de la productividad, donde parecer organizado sustituye a ser efectivo—.
Y aquí está lo que no esperaba.
Ahora construyo sistemas de agentes de IA para vivir. Apila suficientes reglas, guardarraíles y convenciones sobre un agente y se degrada igual que un equipo saturado —más lento, más dubitativo, peores decisiones, hasta que se atasca—. Distinto sustrato. Misma física. El presupuesto de restricciones es real, esté hecho de personas o de tokens lo que ejecuta.
Implementación: la auditoría de resta
Puedes hacerla en una tarde.
- Lista. Escribe cada regla, reunión, checklist, puerta de aprobación y convención vigente bajo la que opera tu equipo. Sin editar aún: el inventario completo.
- Etiqueta. Junto a cada una, escribe el output que produce. No su intención: su output. Sé honesto con las que solo producen sensación de control.
- Corta. Elimina todo lo que no pueda defender su costo. Empieza por las etiquetadas "sin output". Resiste el impulso de guardar cosas "por si acaso".
- Limita. Pon un techo a cuántas restricciones vigentes carga el equipo. Regla nueva que entra, regla vieja que sale.
- Re-mide a 30 días. Mide tiempo de ciclo o throughput antes y después. La recuperación suele ser más rápida de lo que nadie espera, porque no estás añadiendo capacidad: estás devolviendo la que las reglas consumían en silencio.
La misma auditoría funciona sobre el prompt y las herramientas de un agente. Quítale las restricciones que no necesita y observa cómo se afilan sus decisiones.
Takeaway brutalista
No preguntes cuántas reglas necesita tu sistema. Pregunta cuántas puedes eliminar antes de que colapse.
Strip the noise. Ship the work.