Back to blog

Blocker vs Dependency: What's the Difference?

Foundational Guides · 4 min read · 2026-08-16

Blocker and dependency are easy to conflate because they both describe something one piece of work is waiting on -- but only one of them is, by default, a problem.

A blocker is actively preventing progress right now; a dependency is a normal, planned prerequisite that hasn't caused a problem yet -- a dependency only becomes a blocker once it's actually late or missing.

Dependencies are structural, not inherently negative

Dependencies are a structural, expected part of most plans. Task B waiting on task A is normal and not, by itself, worth flagging as a problem.

"The design review depending on marketing's input is a normal dependency -- it's not a blocker yet because marketing is still on schedule."

Notice the framing here: nothing is wrong. The dependency exists, it's on track, and there's nothing to escalate.

The moment a dependency becomes a blocker

The word "blocker" is reserved for the moment a dependency actually fails to deliver on time and starts preventing progress.

"Now that marketing's input is late and nothing else can move, that dependency has become a blocker."

The underlying relationship between the two tasks hasn't changed -- design still depends on marketing's input, exactly as it did before. What changed is that the input is now late, and that lateness is what earns the word "blocker."

Want to learn "Blocker" in depth?

Lyra Practice teaches advanced non-native professionals the nuance of high-value expressions like this one, then has you practice using them in realistic work scenarios.

Start learning for free →

Why over-flagging every dependency backfires

"Listing every upstream dependency as a blocker in the standup makes it hard to tell what's actually stopping work today."

This is the practical cost of skipping the distinction. If every planned prerequisite gets labeled a blocker regardless of whether it's actually late, the standup fills up with noise, and the one dependency that has genuinely turned into a real, active problem gets buried alongside a dozen that are perfectly on schedule.

A simple check before using either word

Before calling something a blocker, ask: is this dependency actually late or missing right now, or is it simply a planned prerequisite that hasn't caused an issue yet? If it's the former, "blocker" is accurate. If it's the latter, "dependency" is the more honest word, and naming it as a dependency -- without the urgency that "blocker" implies -- keeps your status reporting calibrated.

The mistake to avoid

Mistake: treating every dependency as if it were already a blocker. A dependency is a structural relationship; it only becomes a blocker once it actually prevents progress. Reserve the stronger word for the moment it's actually earned.

Dependencies are worth tracking even before they're blockers

None of this means dependencies don't deserve attention before they become blockers -- a well-run project tracks its dependencies precisely so a team can see one drifting off schedule before it turns into an active stoppage. The distinction isn't "ignore dependencies until they're urgent"; it's "use the right word for where a dependency currently stands," which keeps early warning signs and active emergencies from reading the same way in a status update.

Practice scenarios

Practice using blocker in situations like:

Useful practice phrases:

Every blocker starts life as a dependency; not every dependency becomes a blocker.

Reserve the stronger word for the moment it's actually earned.

Lyra Practice helps advanced non-native English professionals learn the nuance of high-value workplace expressions and practice using them in realistic scenarios, so their English sounds natural, precise, and senior at work. Try Lyra Practice.

Think you know this expression?

Take the free 2-minute High-value Workplace Expression Gap Test and see which expressions you should practice.

Take the free challenge

Keep reading