A task is blocked when its owner cannot move it forward because it is waiting on the outcome of another task. It is not slow and it is not neglected. There is simply nothing to work on until the precondition is closed.
That distinction matters more than it first appears. Nothing distorts a team’s picture of its own performance faster than treating waiting as either effort or negligence.
What makes a task blocked
Blocking always comes out of a relationship between tasks. One task is a precondition for another, and until the first is finished, the second one’s outcome would be wrong or meaningless. That relationship is what we call a task dependency, and we covered it in detail in what is a task dependency.
Some common cases:
- proofreading a text before the text exists
- sending a quote before the pricing has been approved
- testing a feature before the development is ready
- getting a contract signed while legal review is still running
What they share is that the second task’s owner can work. Just not on that task.
The difference between a late task and a blocked task
With a late task the deadline has passed and the work is still within the owner’s reach. Maybe they had too much on, maybe they underestimated the effort, but moving it forward is up to them.
With a blocked task, moving it forward is up to someone else. The owner could spend the whole day on it and still get nowhere.
The two are easy to confuse because from the outside they look identical. Both are tasks that are not progressing. The fixes, however, point in opposite directions. A late task needs time or help for the owner. A blocked task needs the precondition closed, and chasing the owner solves nothing.
When the two get mixed up, a quiet unfairness settles into the team. The person who was waiting ends up explaining something they had no control over.
Why blocking stays invisible by default
In most teams blocking travels by word of mouth. Someone asks where a task stands, and it turns out it is waiting on something else. Until that moment the information existed nowhere except in the head of the person waiting.
Two problems follow. First, blocking only surfaces when someone asks, which usually means late. Second, nothing accumulates from it. If one particular precondition has been holding up the same type of work for months, it never becomes a visible pattern.
Hidden waiting is also expensive because it spreads. A blocked task is usually a precondition for something else. That is the subject of why tasks slip when everyone is working.
How to mark a blocked task
Blocking should be recorded where the task itself lives. If it sits in a separate spreadsheet or a message thread, it becomes one more thing to maintain.
In MyPro Sync this follows from the dependency. A task can be marked as blocking another one, and the blocked task automatically carries the blocked flag until the obstacle is cleared. Nothing to set separately and nothing to undo separately.
That has two practical benefits. One is that the task owner knows what they are waiting on and who from. The other is that the manager overview and the dependency graph both show where work is piling up. The same set of tasks appears as a list, a Kanban board, a Gantt timeline and a dependency graph, so blocking is not the privilege of one particular view.
Every status change stays in the log, so afterwards it can be traced how long a task stood still and when it was released.
What to do with a blocked task
Three things help most.
Attention moves to the precondition. If a task is blocked, the work is not on that task but on whatever is holding it up. A status update on a blocked task is not something to expect from its owner.
Waiting is not a performance issue. If the system shows that a task was blocked, nobody has to argue later about what anyone was doing during that period.
Starting on a half-finished basis rarely pays. The temporary workaround is rarely temporary. If a blocked task gets started without the missing precondition, the result usually has to be redone, only later and at greater cost.
Recurring blocks deserve separate attention. If the same precondition holds up work several times a month, that is no longer an isolated case but a process question. At that point the task does not need to be sped up. The way the precondition gets produced needs rethinking.
A first step
Go through the tasks your team currently has standing still, and ask the one question that matters for each of them. Is moving this forward up to its owner, or up to someone else? Wherever the answer is someone else, record the dependency and name the specific task it is waiting on.
That alone will not make the list shorter, but the items on it will finally point to two different problems, and those two call for completely different responses.