The Distance Ledger

Three weeks ago I argued that your organization prices a four-month build off a Tuesday afternoon that went well. Then that the anchor gets set by a sentence nobody wrote down, and that the last mile is most of the road.

All three are the same problem wearing different clothes, and all three happen in the same ten seconds — the ten seconds between a demo ending and somebody saying yes.

So here's what goes on the page before those ten seconds. Three entries, one sheet, and I call it the distance ledger because a ledger is what you keep when you've decided to stop being surprised.

Entry one: the multiple

The distance to real, written as a ratio. Demo took a week, production took sixteen, so the multiple is 16x.

You get this from history rather than from estimation, which is the entire point — three past initiatives, demo date and production date, and the arithmetic does itself. Nobody has to be right about the future. Somebody just has to have written down the past.

A 16x multiple isn't bad news. It's a fact about how your organization converts ideas into running software, and knowing it turns a negotiation into a calculation. The room stops arguing about whether four months is reasonable and starts asking what makes this one different from the last three. Could your organization produce that number today, if somebody asked for it in a review?

Entry two: the named owner of the gap

The gap is everything between the demo and production. Integration, permissions, real data, the eval harness for output that changes every run — and it belongs to a person, with a name, said out loud in the room where the yes gets given.

Not "platform will pick it up." Not "we'll figure out staffing." A name.

This is the entry people fight hardest, and the fight is always procedural — we don't know yet, it's premature, let's not over-plan. That resistance is information. An unnamed owner isn't an open question; it's a decision to let the cost land on whoever is least able to refuse it, made quietly, by a room that would never say so.

An owner you can name is a plan. An owner you can't is a volunteer you haven't met yet.

Entry three: the kill condition, and who can call it

What has to be true for this to stop? And — the half that gets skipped every single time — who is allowed to say so?

I learned this one by losing.

Years ago I tried to get my organization out of a set of expensive AI initiatives. The regulatory picture was turning against us, the efficacy numbers were poor, and I had all of it documented. I made the case properly, in the right rooms, to the right people.

I lost. The portfolio kept the expensive, underperforming practice, and the initiatives that deserved the money starved quietly for another year to pay for it.

The truth is you don't win every battle even when you're right, and I've made peace with that. But here's what I actually got wrong, and it took me a long time to see it: I was arguing for a kill after the fact, in a room where nobody had ever agreed what a kill would look like. There was no pre-agreed trigger. I was asking eight people to admit an error, which is a completely different request from asking them to honour a rule they set themselves back when everyone was calm and nothing was at stake.

Agreement isn't a decision. Set the trigger while the mood is good, and name who gets to pull it, because the person with the evidence is very rarely the person with the authority.

Why a ledger and not a process

Nobody needs another gate. Your organization has plenty of gates, and most of them are theatre performed by tired people. When did a gate last stop anything in your company?

A ledger is different because it's a record rather than a checkpoint. Three lines on one page, filled in before the yes, kept afterward so the next multiple is drawn from real history instead of somebody's optimism. It takes twenty minutes and it compounds — by the fourth entry you're not guessing at all.

Richard Rumelt's argument about strategy applies exactly here: a strategy isn't a goal, it's a diagnosis plus a guiding policy plus coherent action. The demo gives you enthusiasm, and enthusiasm is not a diagnosis. The ledger is the smallest artifact I know of that turns one into the other.

What this looks like when it's working

Picture the next demo. It ends, the room warms toward a yes, and before anyone says "so a few weeks?" you put a single page on the table: multiple, owner, kill condition. Nobody is accused of anything. The conversation reprices itself in about ten seconds, your engineer never has to be the one who says the uncomfortable number, and the decision gets made with the cost attached rather than discovered later.

That's the change. Not slower decisions — decisions with their price tag still on.

You stop being the person who explains four months after the fact, and start being the person who put the four months on the table before anyone committed to two.

This is the kind of thing we build in my workshops, on the team's actual roadmap, in the room, before anybody goes home. But you don't need me for the first one. You need three past initiatives and twenty minutes.

What to stop

Stop treating a demo as evidence of anything except possibility.

Stop letting "platform will handle it" survive contact with a planning meeting.

Stop asking your team to be brave. Bravery is what a system demands when it hasn't got a rule, and you can write the rule this week.

Do this before your next AI yes

Open a document. Three headings: multiple, owner, kill condition.

Fill in the multiple from your last three initiatives. Leave the other two blank, take the page into the next demo review, and fill them in live, in front of everybody.

Watch what happens to the room when the blanks are visible. Then tell me which of the three was hardest to fill — I read every reply, and I'd genuinely like to know whether it's the same one for you as it is for everybody else.