Process Redesign After Plateau¶

A redesign process — instantiates Plateau Detection and Switching

Redesigns the process itself — attacking the binding constraint or changing the architecture — when adding more people, hours, or money stops lifting throughput or quality.

Process Redesign After Plateau is the archetype applied when the plateau is structural. Throughput or quality has stopped responding to added resource, and the reason is not fatigue or saturation of demand but a bottleneck in the process itself: one station, one approval, one shared resource that everything queues behind. This mechanism's distinguishing feature is that the switch is away from adding inputs and toward changing the mechanism — attack the binding constraint, re-sequence the flow, or re-architect the system — because past the constraint, more people or hours pile up as work-in-progress without moving the output. Because a redesign is expensive and disruptive, it first confirms the ceiling is real and structural rather than a transient dip, then locates the actual constraint so the redesign is aimed, not sprayed.

Example¶

A claims-processing office has doubled its staff over a year, but the number of claims closed per week has barely moved and errors have crept up. Adding people isn't working. Process Redesign After Plateau starts by confirming the plateau is structural — the flat throughput persists across months and isn't explained by a seasonal claims surge or a data glitch. Then it maps the flow and finds the constraint: every claim funnels through a single senior adjuster for a mandatory review, and that desk is saturated while everyone downstream idles. The switch is not "hire a fourth reviewer for the same design" but a redesign of the flow — routing low-risk claims around the review entirely, batching the rest, and adding a fast lane — so the bottleneck stops governing the whole line. Throughput rises from the redesign, not from headcount, which had already plateaued precisely because it was feeding a queue in front of the constraint.

How it works¶

Confirm the ceiling is structural. Rule out that the flat throughput is a transient dip, a measurement artifact, or a demand lull before committing to an expensive redesign.
Locate the binding constraint. Map the flow and find the one station, approval, or shared resource that everything queues behind — added resource anywhere else is wasted.
Change the mechanism, not the dose. Re-sequence, offload, parallelize, or re-architect around the constraint — a genuinely different design, not more inputs into the old one.

Tuning parameters¶

Redesign scope — from a targeted constraint fix to a full re-architecture. Narrow fixes are cheap and fast but may just move the bottleneck downstream; broad redesigns address the system but cost and risk more.
Structural-confirmation bar — how much evidence of a real, persistent ceiling is required before redesigning. A high bar prevents costly redesigns of transient dips; too high, and the constraint throttles output for months while evidence accrues.
Constraint-tracking depth — whether to re-locate the constraint after each change. Tracking catches the bottleneck's migration; skipping it risks optimizing a station that's no longer binding.
Disruption tolerance — how much operational upheaval the redesign may impose. Aggressive change unlocks throughput faster but risks a quality dip during transition.

When it helps, and when it misleads¶

Its strength is redirecting effort from the futile ("throw bodies at it") to the effective ("fix the thing everything waits on"). Once a constraint governs a flow, output is capped by that constraint regardless of resource elsewhere — the core insight of the Theory of Constraints, and the reason more input plateaus.^[1]

Its failure mode is redesigning before confirming the plateau is structural — rebuilding a process that was merely having a bad quarter — or fixing the wrong station and simply relocating the bottleneck. Redesign is also seductive as motion: a big, visible change that feels like progress even when the real constraint was a policy nobody wanted to touch. The classic misuse is reorganizing to be seen doing something rather than to move the constrained metric. The discipline is to confirm the structural ceiling first, locate the true constraint before touching anything, and verify throughput actually rose after the redesign rather than assuming it did.

How it implements the components¶

Process Redesign After Plateau fills the structural-switch subset — it changes the mechanism after confirming the ceiling is real and located:

capacity_context_signal — its diagnostic core: identifying that the plateau is a bottleneck/constraint in the process, and which one, so the switch is aimed.
alternative_strategy — the redesign itself: re-sequencing, offloading, or re-architecting around the constraint rather than adding inputs.
false_plateau_check — confirms the throughput ceiling is a persistent structural limit, not a transient dip, before an expensive rebuild is committed.

It does not compute the marginal signal or govern the stop (marginal_response_metric, escalation_stop_rule → Diminishing Returns Detection, Escalation Stop Workflow); it acts once a structural plateau is confirmed.

Instantiates: Plateau Detection and Switching — it is the structural-constraint instance of stop-and-switch.
Sibling mechanisms: Training Plateau Adjustment · Strategy Switch Decision Tree · Diminishing Returns Detection · Marginal Gain Dashboard · Controlled Experiment After Plateau · Escalation Stop Workflow · Plateau Review Cadence · Ad Fatigue Switching · Product Growth Plateau Response · Saturation-Aware Resource Allocation · Expert-Governed Modality Change

References¶

[1] The Theory of Constraints (Goldratt) holds that a system's output is limited by a single binding constraint, so improvement effort spent anywhere else does not raise throughput. It is the reason adding resource away from the bottleneck plateaus, and why the effective switch is to attack the constraint directly. ↩