Split compound blockers into separate obstacles — monolithic problems resist action

Why This Is a Rule

A compound blocker — "I can't launch because we need designs AND the API isn't ready AND legal hasn't approved the terms" — resists action because it feels like one massive problem. The perceived complexity produces paralysis: where do you even start? But the compound blocker is actually three independent obstacles, each with its own owner, its own solution, and its own timeline. Decomposing it converts one paralyzing problem into three manageable ones.

The decomposition must happen before attempting resolution because compound blockers invite compound solutions — elaborate plans that try to address everything at once. These compound solutions inherit the compound blocker's complexity and usually fail. Independent obstacles require independent solutions, which are simpler, can be pursued in parallel, and produce incremental progress as each one resolves.

"Independent owners and solutions" is the decomposition criterion: if two obstacles can be addressed by different people or through different actions, they're separate obstacles bundled into one blocker label.

When This Fires

• When a blocker (Write blockers as 'I cannot [action] because [obstacle]' — vague stuckness becomes solvable) contains the word "and" or lists multiple reasons
• When a problem feels too big to start on
• When a task has been blocked for 48+ hours without progress
• During any problem-solving session where the obstacle feels monolithic

Common Failure Mode

Treating compound blockers as single problems and waiting for a single solution: "We need to sort out the launch requirements" — then waiting for someone to sort out all of them. The compound framing invites passive waiting. The decomposed framing — "Design needs review (owner: Sarah), API needs endpoint (owner: Dev team), Legal needs terms approval (owner: Jay)" — invites parallel action.

The Protocol

When a blocker contains multiple obstacles: (1) List each obstacle separately with its own "I cannot [X] because [Y]" statement. (2) For each: identify the owner (who can resolve this?) and the solution (what action resolves it?). (3) Verify independence: can these obstacles be resolved in parallel, or must they be sequential? (4) Address each independently — the first one resolved reduces the compound blocker from three problems to two, creating momentum that monolithic approaches never achieve.