What came back
The asking is the cheap signal
Eight removals were asked back, all of them inside twelve weeks, none of them expensive.
The daily stand-upBack twice a week instead of five, standing and timed
week 0 · crept back after 3 weeks
Chasing unpaid invoices every weekBack in full
week 3 · crept back after 2 weeks
The spare key logReplaced by something else doing the same job
week 10 · crept back after 14 weeks
Two people on every delivery
week 4 · crept back after 9 weeks
Crept back 4
Four removals were written down with the week each of them stopped. Every one of them produced an event inside the 78 weeks watched. Of these, four crept back. Four of the eleven that crept back without anyone deciding.
Eight people asked for eight things back. Every request arrived inside twelve weeks, at a median of three. None of the eight cost anything beyond the thing itself, and four came back smaller than they had been.
In the internal account of this transition, those eight are the failures: the removals that did not stick. That framing is almost exactly backwards.
What a request actually is
A request is an organisation finding out, early, cheaply, through a channel that costs nothing to run, that a removal was wrong — and finding out from somebody who can say precisely what is missing.
Compare that with the alternative ways of finding out available on this record:
| channel | lag | cost of the discovery |
|---|---|---|
| somebody asks | median 3 weeks | a conversation |
| it quietly reappears | median 7 weeks | invisible drift |
| an external event exposes it | median 31 weeks | whatever broke |
The request channel is the fastest, the clearest and the only one that arrives with a diagnosis attached. The person asking knows what they want and why.
Why it gets read as failure
Because a transition has a number attached to it — thirty-eight removals — and a request reduces the number. The arithmetic of the project says that eight things came back, which is eight fewer than intended.
The arithmetic is wrong in two ways. Four of the eight came back smaller, so the hours did not fully return. And the eight were never the risk: the removals that might sink a shorter week are the ones nobody mentions, and those stay in the total looking like successes.
An organisation optimising for the headcount of removals is optimising to suppress the one signal it can afford.
The suppression is real and it is easy
Nobody has to be told not to ask. It is enough that asking is mildly awkward — that the transition is being reported as a success, that there is a sense that requests are a nuisance, that whoever asks is the person who could not cope.
On this record that did not happen. Eight people asked, nobody was treated badly for it, and the requests were handled on their merits. That is a property of the place and it should not be assumed anywhere else.
Where it does not hold, the eight requests become eight quiet returns or eight slow problems, and the transition reports better numbers while being in considerably worse shape.
The easiest way to improve the removal count is to make asking slightly uncomfortable. It costs nothing, it works immediately, and it converts the cheapest signal available into the most expensive one.
What to do with a request
Three things, in order.
Treat it as information before treating it as a problem. The person is telling you something about the removal that nobody knew. Ask what specifically is missing, which is a different question from whether they want the thing back.
Negotiate the size. Four of the eight on this record came back smaller, and that happened because the hours were genuinely not available and everybody knew it. The conversation produced a version that fitted. This is the best mechanism on the record for arriving at a right-sized procedure, and it only exists because somebody asked.
Record it. The request, the week, and what went back at what weight. Eight entries, a line each. Without this the list says "removed" against eight things that are running again.
The one that did not fit the pattern
Of the eight, one is worth noting as a counter-example. Site visits to the two furthest locations were argued about at the time, removed anyway, and asked back at twelve weeks — much the slowest of the eight.
They came back at thirty per cent: four visits a year instead of monthly. Nobody has reported a difference since.
The slow request turned out to be the one where the original objection was most nearly right and most nearly wrong at once. The visits mattered; the frequency did not. Twelve weeks was how long it took for that distinction to become visible to the person who had argued for them, and it is not clear that any shorter interval would have produced it.
Some requests are slow because the thing is genuinely ambiguous, and the delay is the ambiguity resolving rather than a failure of attention.
What the eight requests had in common
All eight were about something the asker did themselves, every day or every week.
Nobody asked for the return of a procedure performed by somebody else. Nobody asked on behalf of a future colleague, a customer, or a process they were not part of. Every request was first-person and immediate.
That is the exact boundary of what the request channel can report, and it is narrower than it appears from inside. An organisation watching requests arrive is watching a stream of reports about procedures that somebody personally touches often, which excludes anything quarterly, anything owned by nobody, and anything whose beneficiary has not arrived yet.
Three of the five problems on this record fall outside that boundary by construction: an auditor's requirements, a new starter's first week, and a refusal that recurs twice a year.
So the request channel is not a slow version of the problem channel. It covers a different population, it covers that population very well, and the two populations barely overlap.