Dependency test for adjacent steps — does step B require the completed output of step A? If not, they can run in parallel

Why This Is a Rule

Numbered lists imply sequence, and humans default to executing numbered steps in order. But many adjacent steps in a workflow have no actual dependency — they're sequential only because the documentation format is linear. "1. Draft the proposal. 2. Update the project tracker. 3. Schedule the review meeting." Steps 2 and 3 don't require step 1's output; all three could run in parallel. The numbered list created a false serialization that triples the elapsed time.

The dependency test is borrowed directly from critical-path analysis in project management (CPM/PERT): the question "Does B require A's output?" is the fundamental dependency classification that determines which tasks can be parallelized. Applied to personal workflows, it reveals that most "sequences" contain significant parallelizable segments that are invisible because the documentation format imposes linearity.

The binary classification — requires output (sequential) vs. doesn't require output (parallel) — is deliberately simple. Real dependency analysis can be more nuanced (partial dependencies, conditional dependencies), but for personal workflow optimization, the binary question catches 80% of the parallelization opportunities with minimal analytical overhead.

When This Fires

• When reviewing any multi-step workflow for efficiency improvements
• When a workflow takes longer than it should and you suspect unnecessary serialization
• When designing new workflows and deciding which steps must be sequential
• Complements Sequential-by-default is a workflow smell — every numbered list should be questioned for which steps actually depend on which (sequential-by-default as workflow smell) with the specific diagnostic question

Common Failure Mode

Assuming sequence because of presentation order: "Step 1 comes before Step 2, so Step 2 must wait for Step 1." The documentation order is an artifact of writing being linear, not evidence of an actual dependency. Challenge every adjacency.

The Protocol

(1) List all steps in the workflow. (2) For each pair of adjacent steps, ask: "Does step B require the completed output of step A to begin?" (3) If yes → mark as a true dependency (must be sequential). (4) If no → mark as parallelizable. These steps can run simultaneously or in either order. (5) Redraw the workflow as a dependency graph rather than a linear list: parallel steps on the same row, sequential dependencies shown as arrows. The critical path (longest chain of true dependencies) reveals the minimum elapsed time. Everything not on the critical path can run in parallel with it.