Constraint Decay: Why More Process Kills Your Team

Your team isn't slow. It's buried under layers of process nobody questioned. Every methodology, every recurring meeting, every checklist felt reasonable the day it was added — and that's exactly why too much process is so hard to see. None of them is the problem. The accumulation is.

I call it constraint decay. Once you see it, you can't unsee it.

The problem: too much process, not too little

Most teams meet friction by adding structure. A process for this. A convention for that. A template, a ritual, a sign-off. Each new rule looks like control.

It isn't free.

Every rule you add taxes every future decision. It has to be remembered, satisfied, and reconciled with all the others already in place. That tax is paid in the scarcest resource a team has: decision cycles. The cost is invisible at first. The system absorbs it. People adapt. Throughput holds.

Until it doesn't.

The deeper issue: the curve isn't linear

Here's what makes constraint decay dangerous. Performance under accumulating constraints doesn't slope down gently, giving you time to react. It holds, holds, holds — then falls off a cliff.

That nonlinearity is why good teams get blindsided. The dashboards look fine right up to the quarter everything seizes. Nobody can point to the rule that did it, because no single rule did. The weight did.

This isn't a new observation. Fred Brooks documented a version of it in 1975: adding people to a late software project makes it later, because coordination cost grows faster than the work it's supposed to absorb — what we now call Brooks's Law. Constraint decay is the same physics applied to rules instead of people. Coordination overhead has many forms. Headcount is only the famous one.

The BBM approach: subtract, don't add

The instinct, when output drops, is to ask: what process are we missing?

Wrong question.

Ask instead: how many rules can this system lose before it breaks? That single reframe flips the whole exercise from accumulation to subtraction — which is the only direction that actually buys back decision cycles. It's the same discipline behind cutting your tool stack to the bone: the goal isn't zero, it's the smallest set that still ships.

→ Inventory every standing rule, ritual, and convention. All of them, written down. → For each one, name the concrete output it produces. If it produces none, it produces distraction. → Cut anything that can't justify its decision-cycle cost. Default to removal, not retention. → Cap the total. A system has a finite rule budget; spend it deliberately.

The real example: a ~60% collapse

In 25 years building and running multiple SaaS products, I've watched this kill good teams more than once.

One team I watched up close added methodologies, meetings, checklists and conventions over several months. Each addition was defensible in isolation. None was lethal on its own. By the end, output sat roughly -60% below where it started. They didn't collapse from a lack of process. They collapsed under its weight — exactly the productivity theater trap, where looking organized replaces being effective.

Here's the part I didn't expect.

I now build AI agent systems for a living. Pile enough rules, guardrails and conventions onto an agent and it degrades exactly like an overloaded team — slower, more hesitant, worse decisions, until it stalls. Different substrate. Identical physics. The constraint budget is real whether the thing executing it is made of people or tokens.

Implementation: the subtraction audit

You can run this in an afternoon.

1. List. Write down every standing rule, meeting, checklist, approval gate and convention your team operates under. No editing yet — just the full inventory.
2. Tag. Next to each, write the output it produces. Not its intention — its output. Be honest about the ones that produce only the feeling of control.
3. Cut. Remove everything that can't defend its cost. Start with the items tagged "no output." Resist the urge to keep things "just in case."
4. Cap. Set a ceiling on how many standing constraints the team carries. New rule in means an old rule out.
5. Re-measure in 30 days. Track cycle time or throughput before and after. The recovery is usually faster than anyone expects, because you're not adding capacity — you're returning the capacity the rules were quietly consuming.

The same audit works on an agent's prompt and tool set. Strip the constraints it doesn't need and watch its decisions sharpen.

Brutalist takeaway

Don't ask how many rules your system needs. Ask how many you can remove before it collapses.

Strip the noise. Ship the work.