A Blocker Is a Question With a Sleeping Owner

Ask a distributed team what slowed them down last week and you will hear about a staging environment, a flaky test, an API that changed. Then look at where the hours actually went, and it is somebody waiting for somebody else to wake up and confirm something.

"I was blocked all Tuesday." Blocked on what? "I needed to know whether we were still supporting the old export format."

That is not a blocker in the sense any tool means it. It is a question with a sleeping owner, and it is the most common form of waiting on a distributed team.

What actually blocks distributed work

Sort a week of blockers and they fall into four kinds.

• Waiting for an answer. Someone knows, and is not available. Almost always the largest group.
• Waiting for a decision. Nobody has authority, or nobody is sure who does.
• Waiting for access. A permission, a credential, an environment. Small, annoying, and entirely preventable.
• Waiting for work. A genuine dependency on something unfinished. The only one that is really a scheduling problem.

The first two are people shaped, and they are the ones that get worse with distance. The fourth is the one every planning tool is designed around, which is why teams keep reaching for planning tools and keep not fixing the problem.

The field your board is missing

Most boards have a blocked flag. Almost none have a "blocked on whom" field, and that is the field that makes a blocker actionable.

Add two fields wherever your team records work: who it is waiting on, and since when. Both are free to fill in and both change behaviour immediately. A name makes the wait visible to someone who can end it. A timestamp turns a vague sense of slowness into a number a lead can act on.

Within a fortnight you will see the pattern: a small number of names carry most of the waiting, and it is usually the same names as in the key person audit. This is the same finding from the other direction, and it is more convincing when it comes out of the board than out of a survey.

Three ways to shorten the wait

One. Answer forward. When you finish for the day, write down the two or three things the next person is most likely to ask. Costs two minutes, removes a whole round trip. The format is in the end of day handoff.

Two. Widen who may answer. A large share of waiting is people asking the person they trust most rather than the person who is available and competent. Naming a second owner per area does not require anyone to learn anything new on day one. It just gives the question somewhere else to go. See the DRI model.

Three. Make the record answer. This is the one that removes waiting rather than redistributing it, and it is what StandIn is built for. At the end of the day, each person spends about ninety seconds on a brief: what moved, what is open, what is blocked, what is next, mostly drafted from the work that already happened. When someone is offline, their StandIn answers from that brief, in their words, with a source under every answer. It never guesses, and when the answer is not in the record it says so and names who to ask. The "we were still supporting the old export format" question gets answered at 11:00 Tokyo time instead of 09:00 Amsterdam time the following day. See how it works.

Measure blocked hours, not blocked items

Counting blocked items tells you almost nothing, because a blocker resolved in ten minutes and a blocker resolved in three days both count as one. Multiply each by how long it sat and the picture inverts. The item that nobody escalated because it did not feel urgent is usually the most expensive one on the board.

Look at it weekly and look at the distribution rather than the total. A long tail of short waits is a healthy team. A few very long waits is a seam that is not working, and it will be the same seam every week.

Why the standup does not catch these

The daily standup was designed to surface blockers, and on a distributed team it mostly does not. Two reasons. It happens once a day, so a blocker hit at 10:00 sits until tomorrow's standup or until someone chases. And it is attended by people in the same window, so the person who could unblock you is frequently not in the room.

What works better is writing the blocker down at the moment it occurs, with the name and the timestamp, in a place the other zone reads at the start of their day. That is not a meeting change, it is a recording change. The wider case is in replacing the daily standup.

Common Questions

Should people move on to something else while blocked?

Up to a point. Switching has a cost and a half finished task that sits for three days often has to be re read from scratch. Two parallel threads is usually the limit before the switching costs more than the waiting.

How do we handle a blocker that needs a decision nobody can make?

Write the decision as a proposal with a deadline: here is the recommendation, here is what we will do if nobody objects by Thursday. That converts waiting for a decision into waiting for an objection, which usually does not arrive.

Is it rude to name people in a blocked field?

Only if the culture treats it as blame. Framed as routing rather than fault, it is the opposite: it tells the named person what is riding on their reply, which most people want to know.

What about blockers on external parties?

Same two fields, plus a stated fallback for what happens if no reply arrives by a date. External waits are where the "next, if nothing changes" line pays for itself.