Back to blog Browse the expressions hub

Blocker vs Dependency: What's the Difference?

Foundational Guides · 3 min read · 2026-08-16 · Updated 2026-08-27

Professionals comparing a planned bridge segment with a missing segment that has already stopped progress

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.

Quick check: scheduled handoff or blocker today?

Use the delivery plan and today’s date to classify the prerequisite.

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."

Want to actually use "Blocker" naturally at work?

Understanding it is one thing. Practice its nuances, see how it works in real workplace situations, and use it yourself with feedback.

Start the "Blocker" learning path →

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."

Report the moment a handoff becomes a stop

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

Save the stronger word for the point when work stops.

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.

Know "Blocker." What else might you be missing?

The free Workplace English Expression Gap Assessment checks your recognition of high-value expressions across common workplace situations and shows you where your vocabulary gaps may be.

Find my vocabulary gaps

Keep reading