A Power User Is Not a Capability

There's a measure from software engineering called the truck factor: the number of people who would have to be hit by a truck before a project stops. If the answer is one, you don't have a system. You have a person, and a story you tell about a system.

I've been building an argument for a piece of content this week and this is the pillar that kept getting sharper the more I pushed on it. Individual AI fluency looks exactly like organisational AI capability, right up until the fluent individual is unavailable.

Why this specific mistake is so easy to make

Most organisational capability gaps announce themselves. If nobody can run the deployment, deployments don't happen, and you find out on the first Friday.

AI adoption doesn't behave like that, because one skilled operator produces genuinely impressive output. Turnaround times fall. Drafts appear overnight. The work is visibly better and visibly faster, and every dashboard you'd think to build says the adoption is working. The thing you cannot see from any of those numbers is that the improvement is attached to a person rather than to the company.

And the operator's advantage is mostly invisible even to them. It lives in unwritten prompt habits, an instinct for which tasks to hand over and which to refuse, a private sense of when the output is confidently wrong. None of that is in a repository. Most of it has never been said out loud, because nobody experiences their own judgment as a document.

So the failure mode is: you invest in tooling, you get a real productivity gain, you report it as adoption, and your truck factor is one. Which means the capability you just reported has a single point of failure who can resign.

The same shape shows up outside software

I ran into the identical problem this week in a completely different domain — a compliance venture where the evidence required for an accreditation audit lives, in most of the client organisations, in the heads of two or three long-serving staff. Nobody has stolen anything or hidden anything. It's simply that the knowledge of which document proves which requirement was never written down, because the people who hold it have always been there.

That's a truck factor problem wearing a regulatory costume, and the product answer is the same as the AI answer: the value isn't in doing the work faster, it's in migrating the judgment out of individuals and into something that persists.

Once I saw the two side by side, the general shape was hard to unsee. Every domain where an organisation depends on a small number of unusually capable people has the same latent liability, and speed improvements make it worse, not better — because a fast operator has less reason than a slow one to stop and document.

The test

One question, and it's uncomfortable in proportion to how useful it is:

If your best operator went on leave for a month, what stops?

If the answer is "nothing much, it just gets slower," you have a capability. If the answer is a list — and it's usually a list, delivered with a nervous laugh — you have a person, and what you've been measuring is their output, not your adoption.

The follow-up that actually changes something: for each item on the list, what would have to exist in writing for it to not be on the list? Usually a small number of concrete artefacts. The refusal rules — what this person has learned not to hand to a model, and why. The worked examples of tasks that went wrong. The context files they assembled by hand and now reuse without thinking. None of that is hard to write. It's just that nobody's job is to write it, and the person best placed to do it is the person with the least reason to.

Where I'd argue against myself

There is a real phase where a truck factor of one is correct. Early exploration needs somebody moving fast with no obligation to explain themselves, and forcing documentation into that phase kills the exploration and produces documentation of the wrong thing. I'd defend that.

The failure isn't having a power user. It's calling that phase adoption, and budgeting against it as though the capability were institutional. One person going fast is a pilot. It becomes capability at the point where a second person can do the work from the artefacts alone — and that transition doesn't happen on its own, because nothing about the first phase produces pressure toward it.

The honest counter: systematising too early is a genuine and expensive mistake, and plenty of organisations have buried a working practice under process. So the answer isn't "document everything immediately." It's to be precise about which phase you're in, and to stop reporting one as the other.