A blocker is something outside you that has to happen before you can proceed. A signature, a delivery, a decision that isn't yours.
Except that a lot of what gets treated as blocking is nothing of the sort. It's a condition you invented, at some point, quite reasonably — and which has since acquired all the authority of a genuine dependency without ever having earned it.
They're difficult to spot because from the inside they feel identical.
What a self-imposed blocker looks like
Four common shapes.
I need to learn X first. Before building the thing, you need to understand the framework properly. Before writing, you need to read more in the genre. There's usually a real gap in your knowledge, and it's usually much smaller than the preparation being proposed.
It's not ready to show anyone. True of everything at every stage, and therefore useless as a condition. There's no state at which a piece of work announces its own readiness, so this one can run indefinitely.
I need a proper block of time. The work requires four uninterrupted hours, and four uninterrupted hours don't occur. This one is particularly effective because it's often partly true.
I should sort out X first. The other project, the tidying, the thing that would clear the decks. A dependency invented between two unrelated pieces of work.
Each began as a sensible thought. What makes them blockers is that nobody ever went back and checked whether they still applied.
Write it down in the form a real blocker takes: what you're waiting for, and who owes it.
Waiting on the surveyor for the valuation, requested 3 August. That's a blocker. There's a name and a date and someone other than you.
Now try it with the invented kind. Waiting on... myself... to have read enough about the framework. The sentence won't complete properly, and the failure to complete is the diagnosis.
That's the whole test, and it's effective precisely because these things survive on being unexamined. A self-imposed condition can operate for months as a vague sense that something needs to happen first. Asked to name who owes what by when, it collapses in about four seconds.
Why they're so durable
Three reasons.
They're usually true, in a limited sense. You would build the thing better if you understood the framework properly. The work isn't ready. Four hours would help. The falsity isn't in the content, it's in the first — the claim that this must be resolved before anything else can happen.
They feel responsible rather than avoidant. Preparing properly, not showing unfinished work, waiting for conditions that allow you to do it justice — these are the vocabulary of someone taking a thing seriously, which is why nobody challenges them, including you.
And they carry no fault. A goal that's blocked isn't your responsibility this week, and that relief is available immediately and repeatedly. Anything that comfortable will attract goals that don't deserve it.
Converting them back into tasks
Once named, most of these turn into something small.
Need to learn the framework becomes do the authentication tutorial, one evening — a bounded task rather than an open-ended qualification. Then build, and learn the next specific thing when you hit it.
Not ready to show anyone becomes show it to one person who'll be kind, on Thursday. The condition can't be met, so replace it with a date.
Need four hours becomes ninety minutes on Tuesday, on the specific part that fits. If genuinely nothing useful fits in ninety minutes, that's a real constraint and it needs defending in a calendar rather than waiting for.
Should sort out X first usually becomes nothing, because the dependency was invented. Do them in either order, or drop one.
Where the caution is warranted
The honest section, because this argument can be used to bulldoze reasonable judgement.
Some preparation is genuinely necessary, and the anti-preparation position produces people who build things badly and repeatedly. If you'd be making a decision you can't unmake — a technical architecture, a legal structure, a house — then learning first is correct, and calling it avoidance is the more expensive error.
Some things genuinely shouldn't be shown yet, particularly where the audience is one you only get once. An investor, a publisher, a first big client. There's a difference between not ready for anyone and not ready for that person, and the second can be entirely sound.
And some work really does need long blocks, and there's no clever shrinking of it. The distinguishing question isn't whether the condition is true. It's whether you've done anything to satisfy it lately. A person genuinely blocked on learning something is learning it. A person using it as a blocker has been about to start for two months.
Nineteen days on a signature
Ship the beta is marked blocked and has been for nineteen days. The blocker line says waiting on the signed build.
Written out properly — what am I waiting for, and who owes it — the sentence becomes waiting on Priya for the signed build, asked on the 3rd. That's real, and it produces an obvious action: chase, and set a date at which he builds it unsigned.
Underneath it, though, there's a second one that had never been written down at all. He'd decided in August that it should handle recurring appointments before anyone saw it. That decision was made in one evening, by him, and has been operating as a hard requirement ever since.
Attempted in blocker form: waiting on... me... to build a feature I invented in August, for no one who asked for it. It doesn't survive the sentence.
Both come off the same evening. The chase email goes to Priya, and recurring appointments moves to a list of things after the first ten users. What's left is a goal that can move on Thursday, which it hadn't been able to do since August.
What the app asks for
Marking something blocked in goaldrift asks you to say what you're waiting on. That prompt is doing more work than it appears to.
It isn't there for record-keeping. It's there because the act of writing the sentence is what separates a real dependency from an invented one, and most people have never once tried to write theirs down.
The ones that complete get a date and a chase. The ones that don't complete weren't blockers, and they go back to being what they always were — tasks you'd rather not do yet.
Which is a smaller and more useful thing to be looking at. A task you'd rather not do can be shrunk, scheduled, or done badly on a Tuesday. A blocker can only be waited on, and that's the whole reason the mislabelling is expensive.
Related: Stalled vs blocked: the difference that changes what you do next · When you're waiting on somebody else · Side projects that die at 80% done
Share: