A task marked as blocked tells you something is stuck.

But it does not always tell you why.

That is a problem, because “blocked” can mean very different things depending on the situation.

One task may be blocked because a client has not replied. Another may be blocked because a teammate is unavailable. Another may be waiting for a decision, missing information, or depending on work that has not been finished yet.

In all of those cases, the task is blocked.

But the way you unblock it is not the same.

Blocked is not one problem

It is easy to treat blocked work as a simple status.

A task is either blocked or not blocked.

But real work is messier than that.

A blocked task is usually a signal that something in the coordination around the work has broken down.

  • Someone is waiting.
  • Something is unclear.
  • A dependency is not ready.
  • A decision has not been made.
  • A person who needs to move the work forward is unavailable.

That matters because marking a task as blocked is only the first step. The more important question is:

What would unblock this?

Without that answer, “blocked” becomes another label that people ignore.

Common types of blockers

Blocked work is easier to deal with when the team understands what kind of blocker it is.

Here are some common types.

1. Waiting for a decision

Some work cannot move forward until someone makes a call.

This could be a product decision, a design approval, a budget decision, a priority tradeoff, or a client sign-off.

The task may look inactive, but the real problem is not effort. It is decision latency.

Nobody can continue because the next step depends on someone choosing a direction.

This kind of blocker should be visible, because unresolved decisions quietly delay everything downstream.

A better question to ask is:

Who needs to decide, and by when?

2. Waiting for a client or external person

Small teams often depend on people outside the team.

A client needs to send feedback. A supplier needs to confirm something. An accountant needs to provide a document. A freelancer needs to send an asset.

The team may have done its part, but the task is still not moving.

This is one of the most common ways work gets stuck, especially in client-facing teams.

The danger is that external waiting often looks harmless at first.

“Waiting for client” feels normal.

But if nobody follows up, a few quiet days can turn into a delayed delivery.

A better question to ask is:

Who are we waiting on, and when should we follow up?

3. Waiting for another task

Some tasks cannot start until another piece of work is finished.

A developer may be waiting for designs. A designer may be waiting for requirements. A marketing task may depend on a feature being released. A client update may depend on internal work being completed first.

This is dependency blocking.

The risk is that one stuck task can silently delay several others.

If the dependency is not visible, people may keep planning around dates that are no longer realistic.

A better question to ask is:

Which task is blocking this, and who owns that task?

4. Missing information

Sometimes the problem is not a person or a dependency.

Sometimes the team simply does not have enough information to continue.

The brief may be unclear. The requirements may be incomplete. The acceptance criteria may be vague. The task may have been created quickly during a conversation and never properly filled in.

This kind of blocker is common because it often hides behind vague progress.

A task can sit in “in progress” while the person assigned to it is still trying to understand what is actually expected.

A better question to ask is:

What information is missing, and who can provide it?

5. Owner unavailable

A task may be blocked because the person responsible is unavailable.

They may be on leave, overloaded, sick, focused on something more urgent, or simply not able to respond in time.

This is especially important for small teams because there may not be an obvious backup person.

When one person is unavailable, their work can quietly become stuck unless the team notices early.

A better question to ask is:

Should this wait, or should someone else take over?

6. Unclear next step

Not every blocker is obvious.

Sometimes a task is stuck because nobody knows what should happen next.

The title exists. The status exists. Maybe someone is assigned. But the task is vague, too broad, or missing a concrete next action.

This kind of work is dangerous because it can look alive while actually being stalled.

Nobody wants to mark it as blocked because there is no obvious external blocker.

But the work is still not moving.

A better question to ask is:

What is the next concrete action?

Why blocked work spreads delay

Blocked work rarely stays isolated.

One blocked task can delay a handoff.

A delayed handoff can delay another teammate.

A delayed teammate can delay a client update.

A delayed client update can create an urgent meeting.

That is how small blockers turn into team-wide friction.

The problem is not that blockers exist. Blockers are normal.

The problem is when blockers are hidden, vague, or discovered too late.

A small team does not need a complicated process for every blocker. But it does need a simple way to see:

  • what is blocked
  • why it is blocked
  • who can unblock it
  • what needs to happen next

Without that, blocked work becomes invisible drag.

“Blocked” should create action

A blocked status should not be the end of the conversation.

It should start the right conversation.

Not:

This is blocked.

But:

This is blocked because we are waiting for a client reply.

Or:

This is blocked because design is not ready.

Or:

This is blocked because nobody has made the decision yet.

The more specific the blocker is, the easier it is to act on it.

That does not mean every team needs a complex workflow with dozens of blocker categories. But it does mean “blocked” should carry enough context to help the team move.

A good blocked-work system should help answer:

Why is this blocked, who can unblock it, and what needs to happen next?

How SRP thinks about blocked work

SRP is built around the idea that small teams do not just need to track work.

They need to keep work moving.

Blocked work is one of the clearest signs that something needs attention.

But the goal is not just to label a task as blocked. The goal is to make the blocker visible enough that the team can do something about it.

That means helping teams notice work that is:

  • blocked by another task
  • waiting on a client or external person
  • missing information
  • stuck without a clear next step
  • affected by someone’s availability
  • at risk of delaying other work

Because the real value is not knowing that something is blocked.

The real value is knowing what needs to happen next.

Blocked work is not just a status.

It is a signal.

And for small teams, seeing that signal early can be the difference between a small follow-up today and a rushed recovery later.