Have one backup for your constraint step at 80% quality — only the bottleneck needs redundancy
Document one alternative method or backup person who can execute your constraint step at 80% quality to serve as capacity buffer during disruptions, rather than pursuing redundancy everywhere.
Why This Is a Rule
When you — the constraint — are disrupted (sick day, vacation, emergency, burnout), the entire downstream workflow stops. Non-constraint steps can absorb delays without system-level impact. The constraint cannot. One day of constraint downtime equals one day of lost system throughput.
A capacity buffer for the constraint is a documented backup: an alternative method that produces the same output at 80% quality, or a backup person who can execute the step adequately. The 80% quality threshold is deliberate — the backup doesn't need to match your quality. It needs to keep throughput moving during disruptions. 80% quality delivered on time beats 100% quality delivered never.
The rule constrains redundancy to the constraint only because building backups everywhere is expensive and mostly unnecessary. Non-constraint steps have slack that absorbs disruptions naturally. Only the constraint — the step limiting overall throughput — needs explicit backup capacity.
When This Fires
- You are the single point of failure for a critical workflow step
- Planning for vacation, leave, or any planned absence from the constraint role
- After a disruption exposed that no one could cover your constraint step
- During any resilience audit of your personal or team workflow
Common Failure Mode
Pursuing full redundancy: training a backup to 100% quality on every step. This is expensive, often impossible, and mostly unnecessary. The constraint is the only step that needs a backup because it's the only step whose downtime directly reduces system throughput. Train one backup to 80% on the constraint step; leave other steps to self-correct.
The Protocol
(1) Identify your constraint step — the workflow step that limits total throughput. (2) Document the step: what inputs does it need, what does the output look like, what quality criteria must be met? (3) Identify one backup: either an alternative method (simpler tool, templated process) or a person who can learn the step. (4) Train/document to 80% quality — good enough to maintain throughput, not perfect. (5) Test the backup before you need it: have the backup execute the step while you're available to catch issues. A backup you've never tested is a backup that doesn't work.