Split compound blockers into separate obstacles…

When This Fires

• When a blocker (Write blockers as 'I cannot [action] because [obstacle]'…) 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.