Blocker vs Dependency: What's the Difference?

Blocker and dependency sound alike. Both can describe something that work is waiting for, yet only one is a problem by default.

A blocker is stopping work right now. A dependency is a normal, planned need for another step; it becomes a blocker when it is unavailable and stops progress.

A dependency is normal, not a problem

Most plans include dependencies: task B waits for task A. That is normal, so you do not need to flag a problem.

"The design review needs marketing's input. That is a normal dependency, not a blocker, because marketing is still on schedule."

Nothing is wrong here; the dependency exists and remains on track. There is nothing to escalate.

When a dependency becomes a blocker

Use "blocker" when a dependency is unavailable when needed and then stops other work.

"Marketing's input is now late, and nothing else can move. That dependency has become a blocker."

The link between the tasks has not changed; design still needs marketing's input, just as before. The input is now late, and that delay makes it a "blocker."

Why calling every dependency a blocker causes problems

"Listing every earlier dependency as a blocker makes it hard to see what is stopping work today."

If every planned step becomes a blocker, your standup fills with noise, including steps that remain on schedule. A real blocker then gets lost among dependencies that are fine.

A quick check before you pick a word

Before using blocker, ask whether the need is late or missing and stopping work now. Or is it a planned step that has caused no trouble? Use "blocker" for the first case and dependency for the second.

The mistake to avoid

Do not treat every dependency as a blocker. A dependency is a normal, planned need that becomes a blocker when it stops work. Save the stronger word for that point.

Track dependencies before they become blockers

This does not mean ignoring dependencies until they become urgent. Good project teams track them before they fall behind, helping the team spot delays before work stops. The point is to describe each dependency's current state, so early warnings and real emergencies look different in a status update.

Practice scenarios

Practice using blocker in these situations.

• distinguishing a normal, on-schedule dependency from one that has become a genuine blocker
• avoiding the habit of listing every dependency as a blocker in status updates
• recognizing the exact moment a dependency turns into a blocker

Useful phrases to try.

• "[Task] depending on [prerequisite] is a normal dependency -- not a blocker yet, since it's still on schedule."
• "Now that [prerequisite] is late, that dependency has become a blocker."
• "That's a dependency, not a blocker -- nothing is actually stopped yet."

Some blockers arise from dependencies, yet many dependencies never become blockers.

Save the stronger word for the point when work stops.