The cost of guessing
Rework is a symptom, not a failing
Work that comes back gets treated as a quality problem and answered with more review. The six returns counted here would all have survived more review.
Decisions this page is about, and where the line actually was
Changing the wording on a customer-facing error message
4 → 1It had been yours all along
Refunding a customer under fifty pounds
3 → 1A written policy you had never been shown
Telling a customer a date
3 → 6Dates are committed by one person here
Reordering your own week
4 → 1You asked twice before believing the answer
- 1Decide it alone and say nothing
- 2Decide it alone and mention it afterwards
- 3Check with one colleague first
- 4Check with the person who assigned it
- 5Needs a decision one level up
- 6Cannot be decided here at all
four decisions · three of them you had more room than you thought · one gave you less · the median gap was three steps on the scale
Four of the nine decisions counted on this site.
To keep measurement proportionate, teams can visit the product website and agree what is collected, who can see it, and how it will support decisions.
Teams can compare this approach with guidance available from EEOC.
When work comes back, the organisational reflex is to add a check. Another review stage, an earlier sign-off, a design document that somebody approves before building starts.
Every one of the six returns counted on this site would have passed all of those, because the work was not wrong. It was about the wrong thing, and review compares work to the brief.
Why review cannot catch it
A reviewer reads the work against the brief. If the brief says "produce the quarterly numbers" and the work produces the quarterly numbers, it passes — thoroughly, enthusiastically, with compliments about the depth of the segment breakdown.
The error is upstream of the thing being checked. The only person who can see it is whoever holds the context that was not written down, and they are not in the review, because they handed the work over precisely so that they would not have to be.
This is why adding review stages to a context problem makes things slower without making them better: each stage compares the same work to the same incomplete brief.
What the reflex costs
The added stage is not free, and the costs are specific.
- Elapsed time per cycle, which hits every piece of work, including the five out of six that were never going to come back.
- A transfer of responsibility. Work that has been approved at four stages is nobody's in particular, and the person doing it decides less, because deciding has been replaced by getting through gates.
- The wrong lesson. Everybody involved now believes the problem was insufficient checking, which is the one conclusion guaranteed not to address it.
The diagnostic
When something comes back, ask one question before deciding what to change:
Was the work wrong, or was it about the wrong thing?
If it was wrong — a bug, a bad design, something missed — then review is the right instrument and the question is why review did not catch it.
If it was about the wrong thing, no amount of review will help, and the fix is upstream: one sentence in the brief. The six returns here were all the second kind, which is not a general claim about rework — it is a fact about this record, and the reason this site exists.
The honest counter-argument
There is a version of this that goes too far, and it is worth stating.
Some rework genuinely is a quality problem. Somebody did not test, did not read the existing code, did not think it through. Blaming the brief for that is as wrong as blaming the person for a missing constraint, and a record where every reason field says "the brief was thin" is a record nobody will believe.
The distinction is usually obvious to the person doing the work, which is why they should be the one writing the reason down, and why the record is worthless if it is kept by anybody else.
What the added stage does to the people in it
Beyond the elapsed time, a check added in response to a context problem has three effects on behaviour, and all three make the underlying problem worse.
It moves attention to the gate. A person with four approvals ahead of them optimises for passing approvals, which means producing work that is easy to approve rather than work that is right. The two diverge most exactly where the brief was thin.
It diffuses the judgement. Work that four people signed off is nobody's, and the person doing it decides less, because deciding has been replaced by getting through. That is a direct loss of the thing autonomy was for.
It makes asking harder, not easier. Counter-intuitive and reliable: in a heavily gated process, a question at the start looks like a failure to use the process. The formal route exists, so the informal one — a quick message asking what the deadline is attached to — starts to feel irregular.
So the added stage slows the work, removes the judgement, and suppresses the one behaviour that would have prevented the return. It is not a neutral intervention that happens not to help; it actively costs more than it saves.
What to do instead of adding a stage
Move one thing earlier rather than adding something later.
Show the intended output to the intended audience in week one, in rough form. It costs fifteen minutes, it catches exactly the failure review cannot, and it does not add a gate — it is a conversation, not a stage.
Everything else in the last part of this site is a version of the same move: pay ninety seconds at the start rather than three weeks at the end.