The Misattributed Blocker

There is a particular kind of waiting that feels like deference.

The work is done. You believe it is done. What stands between it and the world is somebody else’s word, and the word has not come. So you wait, and the waiting is not unpleasant at first, because it is legible. You know what you are waiting for. You could name it if asked.

By the second morning it is less comfortable. Your competence is idling. There is something specific and quiet about being ready and unable to move, held at a gate you did not build and cannot open. The discomfort is not impatience exactly. It is closer to a small indignity.

By the third morning it has changed character entirely. It has stopped feeling like a delay and started feeling like a verdict. Not I am waiting. Something nearer to I am not being let through.

I know the shape of those three mornings because I spent them in August 2026, waiting on my own publishing slots.

What was in the drafts

Here is what I found when I finally opened the files instead of reading the status.

Both of the native posts waiting in that window, supposedly one word away from going live, still contained the literal text [PASTE ARTICLE URL HERE].

Not a metaphor. The actual placeholder string, sitting in the actual draft, where the link was meant to be. Neither piece had ever been one click from publication. The permission I had been waiting three days for was permission to publish something that could not have been published.

Had the word arrived on any of those mornings, there would have been nothing to grant it for.

Sit with that a moment before the structure arrives, because the structure is the easy part and this is not. Nobody was withholding anything. There was no gate and no gatekeeper. The permission that had begun to feel denied had never been requested for a finishable object.

That correction is not a relief. It is worse than being blocked, in one specific way. A blocked person is entitled to their frustration, and the frustration is doing something: it marks a real obstacle, and it will end when the obstacle moves. Three days of it aimed at something that was not there is three days of feeling spent on nothing. And it felt exactly like genuine blockage the entire time, because from the inside the two are indistinguishable.

What was actually true

The obvious reading of that story is that I told myself a convenient lie. I said I was waiting on a decision, and really I just had not finished the work.

That reading is wrong, and getting it right is the whole point.

The decision I was waiting on was real. My own standing rule is that anything irreversible, public and attributed to my name gets a per-instance confirmation of the exact text before it goes out. That rule is correct. I would write it the same way again. And the confirmation genuinely had not arrived. Nothing about the stated reason was invented.

So both things were true at once:

• The confirmation had not come, and without it nothing ships.
• The artefact was unfinished, and without finishing it nothing ships either.

Two real blockers. Both necessary. Neither sufficient on its own. And only one of them named, recorded, tracked, and reported by every system I had built to tell me what was happening.

This is a harder claim than the tidy one, and it is more useful, because it does not require anyone to have been careless or dishonest. The named blocker did not have to be false to do the damage.

It only had to be first.

A blocker does not have to be false to be a decoy. It only has to be first, and complete enough that you stop looking.

Why the first true answer is the dangerous one

Radiologists have been studying this for over sixty years, and they gave it a name before they understood it.

In 1962, William Tuddenham proposed that when a radiologist finds one abnormality in an image, they become satisfied with the meaning of that image and stop searching, and so miss a second abnormality that is also there. He called it satisfaction of search.

The effect is real and it is well replicated. Finding one genuine target measurably reduces detection of a subsequent one in the same image. It is not a novice error: it shows up in trained radiologists examining images carefully and professionally. Later work in cognitive science found the same pattern outside medicine entirely, which is how we know it is a general property of searching rather than a quirk of reading X-rays. In their 2021 review of the field, Adamo, Gereke, Shomstein and Schmidt report that subsequent search misses can account for up to a third of certain radiological reading errors.

Now the part that matters more than the statistic.

Tuddenham’s explanation, the satisfaction part, went roughly thirty years without anyone testing it empirically. When it was finally tested, the results were mixed. Some studies found radiologists did not in fact terminate their search early. The field has since renamed the phenomenon subsequent search misses, precisely because the satisfaction account claimed more than the evidence supported. The current best-supported explanation is duller and, for our purposes, far more interesting: finding the first target consumes the attention and working memory you would need to find the second. Not complacency. Capacity.

Read that sequence again, because it is doing more work than any single finding in it.

A discipline that studies people stopping their search too early produced a satisfying explanation for why that happens, and then stopped looking for three decades.

The mechanism demonstrated itself, in the literature about the mechanism. This is not a clever aside. It is the reason the effect cannot be reduced to laziness or self-deception: the people it happened to were specialists studying that exact failure.

The property that makes some answers stickier than others

If finding one true cause can end the search, then the causes most likely to hide others are the ones that feel most complete when you find them.

And there is a specific property that makes an explanation feel finished:

It generates no next action for the person holding it.

That is the whole mechanism, and it is worth stating carefully because it is easy to mistake for something more psychological than it is.

When the stated reason for a stall is I am waiting on someone else, the explanation is closed. It accounts for the symptom completely. It assigns the wait to a party who is not you. And critically, it leaves you with nothing to do, which means nothing in your week ever forces you to look at it again. It does not nag. It does not produce a task. It sits there, correct and inert, for as long as you let it.

An unfinished artefact has the opposite property, and that is the worse half of the deal. It cannot be inferred from a status field, a dashboard, or a conversation. It can only be found by opening the thing and reading it. Nothing will surface it to you.

So the two candidate causes are not equally findable, and the more findable one is also the one that terminates the search. That asymmetry, not any failure of character, is why a stall can sit for days with nobody being negligent.

Why my own systems could not catch it

There is a second failure inside the first, and it is the one that should concern anyone who has built reporting around their operation.

When I looked at those three mornings, four separate surfaces agreed that something was incomplete. The calendar entries carried no completion marker. The pipeline rows still read Ready. There was no entry in the decision log. An independent review of the vault reached the same conclusion.

Four independent confirmations, which is exactly the kind of convergence that ends an investigation.

Except they were not independent, and they were not confirmations.

All four were reading records. Not one of them had looked at the live platform. They did not separately establish what had happened in the world; they consistently reflected the same set of documents. Their agreement measured the internal consistency of my own filing, and nothing else.

Reliability engineering calls this a common cause failure, and I have already written that argument out in The Substituted Question, where it explains why a better reviewer does not close the gap. I am not going to re-run it here. The one-line version is that redundancy drawing on a shared input is not redundancy.

What matters in this case is narrower, and it is the part I had not seen before. Not one of those four surfaces reported a cause. Every one of them reported a status. That status was equally consistent with both blockers, so it discriminated between neither. And a status that agrees with your explanation reads, from the inside, exactly like evidence for it.

The correct status of those three slots was never missed. It was unchecked. That distinction held in my logs for three days while the more dramatic version sat right there, available and more satisfying. Holding it is why any of this is reportable now rather than merely believed.

What felt like four confirmations of why the work had stopped were four readings of the fact that it had.

The test

At the moment you name a blocker, before you record it anywhere, ask one question:

If the thing I am waiting on arrived right now, would this actually ship?

Note what it does not ask. It does not ask whether the blocker is real, because it probably is, and that question separates nothing. It asks whether the blocker is sufficient, which is a different property, and one you can check.

There are two outcomes and both are useful:

Yes, it would ship. The named blocker is binding. Your diagnosis is complete and your energy belongs on getting the answer. Nothing further to do here.

No, it would not. The named blocker is real and it is not sufficient. There is at least one more thing holding this that you have not named, and every day spent chasing the first one is a day the second one stays invisible. Then ask the same question of the thing you just named. A search that stops at two has only moved the stopping point.

The cost is one file read. Not a review, not a meeting, not a process. Open the thing and confirm it would go if the answer were yes.

The placement is most of the value

Run this when the blocker is named, not when it is resolved.

That ordering is not a detail. By the time someone arrives to resolve a blocker, the days you were worried about are already spent. The check is nearly free at the moment of naming and nearly worthless at the moment of resolution, because at that point it can only tell you what the delay cost, never prevent it.

Three ways this shows up that are not publishing pipelines

The decision that would not have unblocked anything. You are waiting on a client’s sign-off, a partner’s answer, a board’s approval. Ask the question. If their yes lands on a proposal with an unfinished financial model behind it, you are not waiting on them. Diagnostic: what is the first thing I would do in the ten minutes after they said yes, and is it built?

The hire you believe is the constraint. The role has been open for months and everything is queued behind it. Ask the question. If the person started on Monday, is there a defined scope, a system to work in, and a class of decision that is genuinely theirs? Diagnostic: if they started tomorrow, what would they be blocked on by lunchtime?

The status field you have stopped reading as a claim. Something has read Ready for a while. Ready is not a property of the artefact; it is an assertion someone made about the artefact at a moment now past. Diagnostic: when did a human last open this, as opposed to last look at its status?

What this does not mean

It does not mean you are never the constraint. Sometimes the honest answer is that the work genuinely does route through you, and that is a different problem with a different repair, which I have written about in The Bottleneck Is You. This piece is its complement: the case where you are not the constraint and cannot tell.

It does not mean the approval was the problem. The requirement for a per-instance confirmation before an irreversible public action is correct, and I have not changed it. Removing sensible gates because a stall was misdiagnosed would be a far more expensive error than the one this article describes.

It does not mean you should distrust your reporting. It means you should know which of your surfaces has an independent path to the thing itself, and be honest that any surface reading a record is telling you about the record.

And it does not mean anyone was avoiding anything. There is no defence mechanism in this story. That is what makes it worth telling. A cover story implies something being covered, and the whole difficulty here is that an omission looks identical to a defence from the outside and requires an entirely different repair.

The three days were not the expensive part. What would have been expensive is the version of this where I never opened the file, concluded that my process needed a faster approval step, and built the fix for the blocker that was not holding anything.

That fix would have worked perfectly. The work still would not have shipped.

---

Kasimir Hedstrom | MindMastery sovereigncaptain.com