Backlog bankruptcy: 400 unrecorded nos
· 5 min read · by Tan Gravam
The short answer
A 400-item backlog is not a plan or an asset; it is 400 unrecorded nos — requests that were refused in practice without anyone saying so. Declaring bankruptcy on it does not mean purging it: a mass delete teaches requesters nothing and the requests come back. It means finally making the decisions. Each item leaves as a recorded decline with a reason the requester can read, a park with a review date or an explicit indefinitely, or a survivor — and the test for surviving is not "might be useful" but whether a person in the room will still argue for it out loud.
There is a moment every inherited backlog produces. Item 371, filed twenty-six months ago: "customer wants export to XML". The requester left the company last spring. Nobody will build it, everybody knows nobody will build it, and its status is still "open". Multiply by four hundred and you have most engineering backlogs: not a plan, not an asset — a list of nos that nobody said.
How it got to 400
Every item arrived as a small kindness. "Add it to the backlog" is how conflict-averse organisations say no — it closes the conversation without the cost of refusing. The requester hears "later"; the team means "never"; the backlog holds the gap between them, and the gap accrues interest. Requesters follow up, or worse, stop asking and start escalating. Grooming meetings re-read the same items each quarter and decide nothing about them. The backlog is not free storage. It is deferred refusals, compounding.
Why a purge is the wrong close
The tempting fix is deletion: everything older than a year, gone, fresh start. A purge treats the items as garbage, when the actual problem is that they are undecided — and it destroys the record while teaching nobody anything. The needs did not expire because the rows did, so the requests come back, and this time they arrive pre-escalated, because their requesters have learned that the queue is where requests go to be deleted. Bankruptcy is the right word for what a 400-item backlog needs, but real bankruptcy is not the debt vanishing. It is an orderly, recorded settlement of every claim.
Bankruptcy done properly
Closing a backlog is a batch of decisions, and the exits are the standard exits of demand management: declined, with a reason the requester can read; parked, with a review date or an explicit decision to park indefinitely; or surviving into real consideration. Three exits, plus a housekeeping pile of duplicates and dead links.
The filter for surviving is behavioural, not analytical. Not "might this be useful" — everything might be useful; that test saves all four hundred. The test is: will a person in this room argue for it, out loud, now? A demand with a live advocate is information about what the organisation still wants. A demand with no advocate has already been declined by everyone — in the most expensive possible way, slowly.
A worked example
Arjen takes over a platform team at an insurer and inherits 412 open items, the oldest four and a half years. He runs three two-hour sessions with his tech leads and both product managers, walking the list oldest first. The arithmetic at the end: 58 duplicates or dead on arrival. 217 declined, each with a one-line reason — the most common being some version of "nobody present will argue for this". 94 parked — 83 with review dates, 11 explicitly indefinite, because pretending a review date exists is its own small lie. 43 survive, each because somebody in the room made a case out loud.
The declines went back to their requesters where the requester still existed — about 140 short messages, sent in batches over a week. Nine people replied. Seven said some version of "fair enough — thanks for actually answering". Two argued, and both arguments were good, so both items came back sharpened and survived on their second pass. That is not the process failing; that is the process finally working — a no that can be contested beats a maybe that cannot be found. Total cost: six working hours in a room plus an afternoon of messages, against a debt that had been compounding for four years.
Keeping it at zero
A bankruptcy that does not change the door refills within eighteen months. Two changes keep the ledger clean. At the door: requests that state no need, no affected party and no consequence go back with one question at arrival — while the requester still has the context — rather than into storage. And culturally: the no gets cheap. A recorded decline costs one sentence when the request arrives and costs the relationship nothing; it is the slow maybe, excavated years later in a bankruptcy session, that costs. The healthiest thing about the thirty-item backlog Arjen runs now is not the number. It is that every item on it has someone who will still argue for it.
I'm Tan Gravam. I build DeliverySheet — it takes a vague work request to a clear delivery decision, so the shape, owner, capacity, dependencies and open questions are on the table before anyone commits people or a date.
$189/month per workspace, unlimited members, 7-day free trial. I answer the support email myself.
More on turning a request into a decision
Read the overview: Turning a request into something you can decide on →
- The engineering intake process, end to end
One door, two questions, four recorded exits. The whole intake process for an engineering team — without a triage committee or a twelve-field form.
- An intake form template with two required fields
A copy-paste intake form template for engineering teams: two required questions, one optional date, and the four exits every request must reach.
- Triage is deciding what happens next, not sorting by size
Request triage fails when it produces an ordering instead of decisions. The four exits, who sits in the room, and the fifteen-minute version.