Scaling proposal

Written by a person. Last read by a person on 2026-09-07, 1 day ago. Its facts were checked by the eval suite on 2026-09-07.

You want to know whether this works without its author, or you are looking for kill criteria.

Scenario-based sample. Halden Systems is invented, and so is every figure about it.

How the program reaches all 9 Halden Systems sites.

Bottom line. This has to run without the person who designed it. One unit is 1 local expert supporting 25 people for 6 weeks, at about $4,100 of time nobody is currently accounting for. 9 sites need 46 units over 18 months. If the unit cannot be run by somebody who did not design it, we stop, and the kill criteria below say when.

What one unit is

The unit is a person at a site, not a course in a catalog. That follows from the evidence: a 22-point confidence gap between sites with a local expert and sites without one is wider than the gap between job families, so proximity to help predicts capability better than role does.

The direct cost is genuinely zero and the time cost is genuinely $4,100. Reporting only the first is how programs get approved and then quietly starve.

Dublin ran this once already and produced median days to a first merged change of 9 against a company median of 41.

The train-the-trainer path

A unit is run by somebody who was in the previous unit. That is the mechanism, and it is why the program compounds rather than scaling linearly with the founder's calendar.

A site is self-sufficient when it has 2 people at stage 4. 4 sites have somebody at stage 1 today, which is where the 22-point gap comes from, and 5 have nobody at all.

The material a new expert needs is a runbook, a session outline and the assessment. All 3 exist already, which is what makes stage 3 a real handover rather than an aspiration.

What breaks at 10 times the size

Named specifically, because a caveat that says "scaling brings challenges" tells a reader nothing and costs whoever wrote it nothing.

The check-in does not scale and fails silently. At stage 3 the enablement function spends 30 minutes a week per new expert. At 46 concurrent units that is 23 hours a week against a function of 2.5 people. It breaks somewhere around 20 concurrent units, and the failure mode is not a crisis, it is check-ins quietly being skipped. Fix: stage 4 experts take the check-ins from unit 15 onward, which is why stage 4 exists.

Content goes stale faster than 2.5 people can revise it. 140 units against 4 engineering systems that ship continuously. At the current change rate, roughly 12% of the content is wrong at any moment. Fix: content ownership moves to the teams that own each system, with the enablement function holding the standard rather than the text.

Assessment integrity. At 25 people a facilitator knows whether somebody understood. At 1,150 they do not, and the assessment becomes the only signal at exactly the point where it starts being gamed. Fix: assessment against a real change in a real repository, which cannot be answered from a recording.

The 5 sites with nobody to ask stay last. Every scaling plan reaches the sites that already have an expert first, because those go faster, and the 22-point gap is at the other 5. Fix: the sequence is fixed in the project plan and starts at 2 of the 5, which costs us speed in year 1 on purpose.

Kill criteria

The conditions under which we stop. A scaling proposal with no such condition is a budget request wearing a plan's clothes.

The last row is the one that matters. A program that cannot describe the world in which it should not exist is asking for trust rather than a decision, and the person being asked can tell.

Stopping is not failure in 2 of these 5 cases. It is the finding.