Why "blocked" is the wrong word

When a software task can't proceed because something it depends on isn't done, project tools call this "blocked." The word is wrong, and the wrongness shapes how teams think about the work.

"Blocked" implies failure. A blocked task is stuck. Something has gone wrong. Someone needs to unblock it. The word carries connotations of obstruction, delay, and intervention. Daily standups are full of "I'm blocked on X" reports that read as escalations: this isn't working, somebody fix it.

The reality is that most "blocked" tasks aren't blocked. They're locked. Their prerequisites haven't completed yet, exactly as planned. Nothing has gone wrong. The system is working as designed. Calling this state "blocked" pathologizes a normal part of how dependent work proceeds.

This is a small linguistic point with large consequences for how teams operate.

What "blocked" assumes

The word "blocked" assumes a baseline where work flows freely and obstruction is the exception. The default is movement. Blockage is interruption.

This frame fits some kinds of work. A bug fix that's waiting on a code review is genuinely blocked: the work could proceed, except for something specific that needs to happen. The reviewer is the bottleneck. Removing them removes the block.

But the frame doesn't fit dependent work. A task that depends on three prerequisites isn't "blocked" until those prerequisites complete. It hasn't started yet because it can't start yet. The state is the structural default, not an interruption to flow.

When teams use "blocked" for both situations, the distinction collapses. Tasks waiting on review and tasks waiting on prerequisites get reported the same way. Both look like problems. Neither feels normal. The team's mental model becomes one where dependency is dysfunction, which is the opposite of how dependent work actually works.

What "locked" gets right

The alternative we use in Tree is "locked." A locked task is one whose prerequisites haven't all completed. The word borrows from game design, specifically from progression UI in strategy games where future abilities are visible but unavailable until you research the requirements.

"Locked" implies the system is working as designed. The task isn't broken. It isn't stuck. It hasn't started because its prerequisites haven't finished, which is the planned and expected state. A locked node will become available when its prerequisites resolve. Nothing needs to be fixed.

The word changes how teams report status. "I'm locked on X" sounds different from "I'm blocked on X." The first reports a structural fact about the project graph. The second reports a problem that needs intervention. They're describing the same situation, but the affective load is different, and the affective load shapes behavior.

A team that uses "locked" stops escalating dependency states as if they were problems. They report "Task Y is locked behind Task X" as a neutral statement, the way a game player would say "I haven't researched that yet." The implicit question changes from "how do we fix this" to "what's the right thing to work on now."

The available tier

Once "locked" is the default state for waiting work, the natural counterpart is "available." Available tasks are the ones whose prerequisites are all complete and that haven't been started yet. They're the work the team can pick up right now.

The available tier is computed continuously from the graph. It's not a list someone curated. It's the leaves of a topological sort, freshly evaluated as nodes complete. When you finish a task, the graph re-evaluates and the available tier updates. New work appears. The team's "what should I work on" question has a mechanical answer.

This is a different shape than "the backlog." A backlog is a curated, prioritized list of pending work. Maintaining it is a job. Reading it is a job. Ranking the items is a job. The backlog is large, ambiguous, and always slightly out of date.

The available tier is small, mechanically computed, and always current. It contains only the work that can actually start now. The size is bounded by the structure of the graph, not by the team's grooming discipline. If the available tier feels too small, the team plants more entry-point work. If it feels too large, they accept that they're in a phase with a lot of unblocked surface.

This is, again, borrowed from games. Civilization V's available techs at any point are a small set, usually four or five, computed from what you've already researched. The game doesn't show you a backlog of all 80 techs and ask you to prioritize. It shows you what you can pick now, given what you've already done. The mental load is structural, not cognitive.

What this changes

The vocabulary shift produces three behavioral changes.

The team stops treating dependency as dysfunction. Locked tasks aren't problems. They're the planned state of work that will become available later. The team's focus shifts from "unblocking" everything to working through the graph in the order the structure permits.

The team gets a real to-do list. The available tier is the actual answer to "what should I work on right now." It's smaller than the backlog, more current, and computed instead of curated. The team's daily decision-making becomes lighter because the answer is mechanical.

The team gets clearer status reports. "Task Y is locked behind Tasks X1 and X2, which are in progress" is a complete status update. The team knows what's happening, what's expected, and what's coming next without anyone needing to investigate. The graph carries the information.

None of this requires changing the work. The vocabulary is doing the work. Calling the same state by a different word changes how the team relates to it.

What about real blocks?

Real blocks still exist. A task that's waiting on a vendor decision, a code review, a stakeholder approval, or an external dependency is genuinely blocked. The word fits.

The right vocabulary distinguishes the two. "Locked" for structural waiting (prerequisites haven't completed). "Blocked" for situational waiting (something specific needs to happen that should have happened by now). Both states are real. They need different treatment.

A locked task waits for the graph to advance. A blocked task waits for an intervention.

A locked task is normal. A blocked task is a flag.

A locked task should be reported as a fact. A blocked task should be reported as an escalation.

The teams who get this right have lower-friction operations because they're not treating every dependency state as an emergency. The teams who don't get this right have noisier standups, more escalations, and worse signal-to-noise on what actually needs intervention.

The summary

"Blocked" is the wrong default word for tasks waiting on prerequisites. It pathologizes a normal state and shapes teams toward unnecessary escalation.

"Locked" is the right word. It treats structural waiting as the default and reserves "blocked" for situations that genuinely need intervention.

The vocabulary is small. The behavioral effects are large. Teams that adopt the distinction operate with less noise and clearer signals.

If you want a project tool that uses the right word, join the waitlist.