The Difference Between a Blocker and a Question

A developer on a team I worked with once marked a task blocked because the API response didn't specify a timezone. He moved on to something else. Nobody noticed for a day and a half, because in his channel, blocked meant the same thing as done for now — a state you exit, not a state anyone has to actively resolve.

When his lead finally saw it, the question took forty seconds to answer: UTC, like everything else in that service. The task had been sitting for a day and a half over a default that was already true everywhere else in the codebase.

Calling everything a blocker is its own kind of failure

On a distributed team, the word "blocked" does two jobs. It's supposed to mean the work genuinely cannot proceed without someone else's input. It also gets used, quietly, to mean "I have a question and I'd rather stop than guess." Those are different problems with different costs, and treating them the same one slows everyone down.

A real blocker justifies stopping. A question usually doesn't. The task can keep moving on a documented assumption while the question sits in someone's inbox waiting for an answer that doesn't need to arrive in the next ten minutes.

The test: can you produce a defensible wrong answer?

Here's the distinction I actually use, and I've watched it hold up across three very different teams:

• If any reasonable choice you could make would need to be undone or would break something else later, it's a blocker.
• If a reasonable choice lets you keep working, and the worst case is a small, visible correction later, it's a question — proceed on the assumption and flag it.
• If you're stopping because you're not sure and haven't tried to find out, it's neither. It's avoidance wearing a blocker's name tag.

Three examples, worked through

A checkout flow needs a currency symbol and the ticket doesn't say which. You default to the store's primary currency, note the assumption in the task, and keep building. If it's wrong, it's a one-line fix later. Question, not blocker.

A migration script needs to know whether it's safe to drop a column that three other services might still read from. Guessing wrong here doesn't cost a line fix — it costs a rollback, a postmortem, and possibly lost data. Blocker, full stop.

A designer hands off a screen with no state for an empty list. You could invent one, ship it, and revise it in twenty minutes if it's off-brand. Question. But if the empty state changes what happens to a delete button that's already wired up for the populated case, and getting it wrong means redoing the wiring — that tips it toward a blocker, because now the wrong guess costs more than the wait.

The pattern underneath all three: the size of the correction, not the size of the uncertainty, decides which one you're looking at. Plenty of blockers feel small when you're naming them and turn out huge once you've built on the wrong guess. Plenty of questions feel important and turn out cheap to be wrong about.

A decision tree you can actually apply mid-task

Am I unsure how to proceed?
├─ No → keep going.
└─ Yes
   ├─ Would a wrong guess be cheap to fix later?
   │  └─ Yes → make the call, document the assumption, keep going.
   │           This is a QUESTION, not a blocker.
   └─ Would a wrong guess be expensive, irreversible, or
      block someone else's work if wrong?
      └─ Yes → this is a BLOCKER.
               Stop only the part that depends on the answer.
               Everything else on the task keeps moving.

Notice the last line. Even a real blocker rarely stops an entire task. It stops the one piece that depends on the unknown. The rest of the ticket — the parts that don't touch the uncertain bit — can keep moving while the question sits with whoever can answer it.

Writing a question someone can answer without a meeting

A blocker that gets phrased like a blocker is easy to spot but often hard to answer, because it arrives as a wall of context and an implicit demand for a synchronous conversation. A question that's actually a question needs the opposite: enough context to answer without a call, and a stated default so the answer is a yes or a correction, not a blank page.

“Assuming USD for now since the rest of the checkout flow uses it. Flag me if that's wrong and I'll swap it — shouldn't take more than a few minutes.”

Compare that to the version that actually blocks someone's afternoon:

“Hey, quick question about the checkout flow, do you have a sec to hop on a call?”

The first message is answerable from a phone, between meetings, by someone who has never opened the ticket. The second requires the recipient to context-switch into a synchronous conversation for something that, ninety percent of the time, didn't need one.

1. State what you're going to assume if nobody answers.
2. State the actual question, specifically enough that a one-word reply resolves it.
3. State what happens if the assumption is wrong — usually "I'll fix it," which reassures the other person it's low stakes.
4. Send it and keep working on whatever doesn't depend on the answer.

Why this matters more once your team is spread across time zones

In an office, the cost of misusing "blocked" is small — you can lean over a desk. On a distributed team, a blocker flag sits for however many hours separate you from the person who can answer it. If half your uncertainties are actually questions with a safe default, and you're calling them all blockers, you've built in a full day's delay on things that could have shipped by lunch.

This is part of why a checklist task benefits from more than one flavor of "something's wrong here." A row that's genuinely stuck, a row where someone just needs to weigh in, and a row where you have a question but you're still moving — those aren't the same signal, and collapsing them into one red flag trains people to ignore it, or to treat every flag as urgent regardless of whether it is.

The habit worth building isn't "ask fewer questions." It's noticing, before you stop, whether the wrong guess actually costs anything. Most of the time it doesn't. Write the assumption down, keep moving, and let the question find its answer on its own schedule.