Teams use "blocked" for almost everything that is not moving.

That makes the word nearly useless.

A decision is missing: blocked. Another team has not finished its part: blocked. The customer has not replied: blocked. The request does not fit the normal policy: blocked. The owner is overloaded: blocked. The task is unclear: blocked. Nobody wants to do it: blocked.

One label, six different interventions.

A workflow ontology should separate blockers, dependencies, and exceptions because they require different management behavior.

A blocker is an obstacle that prevents progress and needs intervention. The key phrase is needs intervention. If the owner can resolve it through normal work, it may be friction, not a blocker. Real blockers should trigger escalation, decision, reallocation, or explicit acceptance of delay.

A dependency is something the work needs from another person, team, system, vendor, customer, or event. Dependencies are not inherently bad. Most meaningful work has them. The problem is unmanaged dependencies: no owner, no due date, no confidence level, no fallback path, no visibility when the date slips.

An exception is a case that does not fit the standard workflow. Exceptions are where policies meet reality. A customer needs nonstandard terms. A security review finds an unusual risk. A refund request is outside the normal window. A product launch breaks the normal release path. Exceptions need judgment and a handling rule, not a permanent status called "weird."

When teams collapse these into one blocked bucket, leaders cannot tell what kind of help is needed. They ask for updates instead of removing constraints.

A clean blocker record should answer:

  • What specifically prevents progress?
  • Who can remove it?
  • What decision, action, or information is required?
  • When does the delay become unacceptable?
  • What workaround exists if the blocker remains?

A clean dependency record should answer:

  • What object does this work depend on?
  • Who owns that object?
  • What date or condition matters?
  • How confident are we?
  • What downstream work is affected if it slips?

A clean exception record should answer:

  • Which rule or path does this case violate?
  • Who has authority to approve the exception?
  • What risk are we accepting?
  • Should the normal workflow change if this repeats?

That last question is important. Repeated exceptions are usually process feedback. If every enterprise deal needs custom security review, the exception is no longer exceptional. If every implementation has a data migration surprise, the workflow is missing an object. If every refund needs executive judgment, the policy is underdesigned.

Blockers tell you where work needs intervention. Dependencies tell you where coordination risk lives. Exceptions tell you where the standard model is incomplete.

Different signal. Different response.

The useful management move is to review stuck work by cause, not by mood. How much work is waiting on decisions? How much is waiting on other teams? How much is customer-delayed? How much is exception handling? How much is simply unclear?

Once the causes are visible, the operating fixes become less heroic. Add a decision forum. Create dependency owners. Set review SLAs. Rewrite the policy. Close stale requests. Build a standard exception path.

Calling everything blocked feels honest because it admits delay. It is still too vague to manage. Name the shape of the stuckness.

This is part 6 of 10 in Workflow Ontology.