Issue Summary
In most manufacturing environments, we are trained to look for bottlenecks in the physical world. We walk the floor and identify the machine that’s running at 100% capacity while everything else waits on it. We look at the trucking dock and see a pile of containers waiting for a forklift or an open bay. These are real constraints—physical, visible, and measurable. If you optimize these, things move faster.
But there is another bottleneck that doesn't show up on a heat map or a production schedule: The Decision Backlog.
This is the accumulation of unresolved exceptions, "pending" approvals, and stalled queries that keep parts from moving, machines from running, and teams from executing. It is an operational constraint disguised as administrative overhead. When a part sits in a bin because someone is waiting for a quality sign-off on a minor deviation, or when a production run is paused because a supplier’s substitution hasn't been officially "blessed," the bottleneck isn't the dock—it's the lack of a decision. This issue explores how we must stop treating decisions as an infinite resource and start managing them with the same rigor we apply to machine uptime and inventory levels.
The Hidden Constraint: Naming the Decision Backlog
I’ve spent enough time on shop floors to know that "waiting" is rarely just about a slow forklift. Often, it's about a person—or a group of people—who are paralyzed by an unresolved choice. We need to give this problem a name so we can manage it: The Decision Backlog.
A Decision Backlog is any operational exception that has been identified but not resolved. It is the "debris" of management. In many plants, these exceptions pile up in emails, on sticky notes, or in some shared spreadsheet that nobody actually updates. Because these items don't have a physical footprint, they are invisible to most capacity planning models.
Think about it this way: If a conveyor belt is jammed with a piece of scrap metal, you see the jam and clear it. A Decision Backlog is like a microscopic grain of sand in every gear of your operation. One grain doesn't stop the machine; ten grains don't either. But when enough of them accumulate, the entire system begins to grind, lose heat, and eventually seize up. We treat these as "paperwork" problems, but they are actually flow problems. When a decision is pending, the work has stopped. Period. The fact that it’s a mental block rather than a mechanical one doesn't make it any less of a constraint on your first-pass yield or your lead times.
Why We Treat Decisions Like They Are Free
The reason the Decision Backlog persists is rooted in a fundamental organizational lie: we assume that making decisions costs nothing. We treat decision-making as an infinite resource, while we treat machine hours, floor space, and labor as finite resources.
Because "thinking" doesn't require a capital expenditure or a scheduled shift change, it gets pushed to the back of the priority list until it becomes an emergency. We allow these decisions to sit in a holding pattern because the cost of making the decision feels higher than the cost of waiting—at least in the short term. It’s a comfortable denial that keeps things moving just enough to avoid a crisis, even as the underlying flow degrades.
| The Comfortable Rationalization | The Underlying Reality |
|---|---|
| "We're just waiting on engineering to sign off." | A decision is trapped in a loop because no one has been given the authority to say 'yes.' |
| "It’s such a minor exception, it shouldn't matter." | The cumulative weight of these 'minor' exceptions creates a logjam that halts your overall flow. |
| "We need more data before we can make a call." | We are using data-gathering as a shield to avoid making an uncomfortable or unpopular choice. |
| "Someone will eventually get around to it." | The backlog is growing, and the 'someone' is currently overwhelmed by the sheer volume of unresolved items. |
What Does a Decision Backlog Cost You? The Metrics That Matter
When we ignore the Decision Backlog, we aren't just being disorganized; we are leaking profit and capacity every single hour. To fix this, we have to stop looking at "pending emails" as an administrative annoyance and start seeing them as lost production time.
The costs of a Decision Backlog manifest in three concrete ways:
- Lost Production Capacity: Every minute a machine sits idle because a technician is waiting for a deviation approval is a minute of capacity that can never be recovered. If you have five machines stalled by "pending" decisions, your effective capacity just dropped by 20%.
- Escalating Expediting Fees: When the backlog finally causes a missed delivery window, the reaction is usually to throw money at the problem—overtime, hot-shot trucking, and rush fees from sub-suppliers. These are "penalty costs" for failing to manage the flow of decisions earlier in the process.
- Eroded Trust and Motivation: This is the most insidious cost. When operators see that their work is constantly stalled by a backlog they have no power to clear, they stop trying to find ways around it. They revert to "safe" behaviors or unofficial workarounds because the official path is clogged with indecision.
The avoided conversation today—the one where you decide how to handle a non-conforming part—is often uncomfortable. But the delayed consequence of that decision is usually more expensive, more public, and much harder to recover from.
The Fix: Treating Decisions as Limited Resources
To clear the backlog, we have to stop treating decisions like they are free and start managing them as a finite operational resource. If you can't manage your machine maintenance schedule, you shouldn't be surprised when you can't manage your decision flow.
We need to move toward a model of Decision Capacity Management. This involves three specific shifts in how you run the floor:
1. Define Decision Rights (Selective Autonomy)
Most backlogs exist because too many decisions require "high-level" approval. We need to push decision rights down to the point of impact. If an operator can solve a problem without calling a manager, they should have the authority to do so—provided there is a clear framework for doing it safely. Define what constitutes a "Standard Deviation" (which can be handled on the floor) versus a "Systemic Exception" (which requires a formal review).
2. Audit and Purge the Backlog
You cannot manage what you haven't measured. Conduct a "Decision Audit." Go through every pending exception in your current supply chain or production flow. Categorize them: Can we decide this now? Do we need more data? Or is this no longer relevant? Clear the junk out of the system to see what’s actually left.
3. Schedule Decision Maintenance
Just as you have a Tier board for daily production issues, you need a cadence for clearing the decision backlog. Treat it like "maintenance" on your process flow. Set aside time—daily or weekly—specifically to review and close out pending exceptions. If a decision hasn't been made in 48 hours, it should trigger an automatic escalation.
The goal is not to make every decision faster; the goal is to ensure that no decision stays "pending" long enough to become a bottleneck. We need to move from a culture of waiting for permission to a culture of executing within authority.
Download and Share This Issue
Call to Action
What metric do you use today to measure 'decision capacity' on your floor? Share a quick example with us, and don’t forget to pass this along to another operations leader who needs an honest diagnosis.
Newsletter replies and questions: [email protected]
Follow updates on X.com: @kaizen6sigma