Outsource Knowledge, Insource Thinking

A senior enterprise rep hands in her notice. The handover is clean: pipeline updated, meetings reassigned, files in order. What she cannot hand over is everything that was never written down. Who on the account has budget authority and who only has the title. Which competitor nearly displaced the product last spring. Why the CFO stopped answering email in March. Her replacement calls the wrong person, pitches the wrong problem, and loses a renewal the company had held for six years.

The post-mortem called it a transition cost.

So they fixed it, and they fixed it thoroughly. Playbooks. Competitive intelligence. Objection scripts. Account notes going back years, searchable, maintained by someone whose job it now was. Eighteen months later another rep worked an account with all of that in front of him. He wrote a proposal that met every documented criterion and lost to a competitor who offered less. The buyer wanted cover for a compliance risk that no playbook mentioned, because playbooks record what buyers said last year rather than what this one is afraid of now.

He had every fact and no read on the room.

The second failure came through the door the first one's fix opened.

Two failures that look the same

Knowledge is anything that stays useful after you write it down: facts, procedures, histories, standards, who decided what and why. It transfers by reading.

Thinking is what you do when the written material does not fit the situation in front of you: diagnosis, judgment, adaptation. It transfers by practice, and only by practice. You can describe how a senior engineer knew the fault was upstream before she ran a single check. The reader finishes the description and still cannot do it. She learned it by sitting with ambiguous incidents, being wrong often enough to stop trusting her first read, and noticing afterwards what she had missed.

The sales company got its first diagnosis right. A knowledge failure is exactly what documentation answers, and they built the documentation well. What they missed was the boundary: they kept going until following the page had replaced reading the room, which is how the cure for one failure becomes the cause of the other.

The inversion

In a typical organization the knowledge is insourced, in the worst sense of the word. The deployment quirks live in one engineer's head, the account history in one rep's, the real decision structure (who decides, rather than who signs) in nobody's files at all. The organization keeps its facts in the most volatile storage it owns: people, who forget and who leave.

The thinking, meanwhile, is outsourced. A consultant delivers the diagnosis. A maturity model makes the decisions, telling you what to do next quarter so nobody has to. A dashboard handles the evaluation, because when the metric moves everyone treats the movement as the finding. And now a model writes the analysis, fluently, on demand.

Nobody designed this. Each step was locally reasonable: writing things down felt slow while the expert was sitting right there, and buying judgment felt fast, especially with a big-four logo on the slide deck. Add the steps up and you get an organization that rents its judgment from parties who carry none of the consequences, while its facts walk out the door with every resignation.

Outside judgment is sometimes exactly what a situation needs. An organization cannot see its own structure from inside it, which is the whole reason the outsider gets called, and nobody develops their own tax counsel. That objection holds. What it licenses is narrower: a firm that sells you the conclusion and keeps the reasoning has sold you one decision, and you will be back for the next one. The test is not whether the judgment came from outside. It is whether any of it stayed.

The order of the sentence is not the order of the work

The principle is one sentence: outsource knowledge, insource thinking. Move the facts out of heads and into documentation that gets verified. Move the judgment back in: your own people, practicing on your own cases, wrong in front of each other and better for it.

The sentence puts knowledge first because it reads better that way. The work runs in the opposite order, because of an asymmetry. Someone who can read a situation will work around a thin page. A thorough page rescues nobody who cannot read the situation. Compensation runs one way only, so the capability that compensates gets built first.

A team I worked with sequenced it that way deliberately. Practice came first, and the documentation push started later, once that was running. Do it the other way round and you arrive at excellent documentation with nobody left who can tell when it stopped being true.

Thinking moves through practice, and practice needs friction. A junior learns diagnosis by pairing on the investigation and being asked afterwards where the senior changed direction, and why. A debrief does the same work when it includes the questions people would rather skip: where was my diagnosis wrong, where did I act too early, what did I avoid confronting. In a group session the challenge has to be somebody's assignment rather than their mood: you say this is a dependency problem, so what evidence would tell you it is a design problem instead. The moment those sessions turn polite, they are theatre.

The friction has a name. In 1994 Robert Bjork called these conditions desirable difficulties: the ones that make learning feel harder produce stronger and more durable retention, while the ones that make performance improve quickly tend to collapse on contact with an unfamiliar situation. A team that is never wrong in front of each other has arranged never to find out. And because this half has no completion state, it needs a signal instead: you know it is working when people start bringing live problems for challenge before anyone asks them to.

What the page cannot tell you

The other half fails through overreach or decay. Overreach is the documentation project that tries to capture everything and dies under its own weight. The working test is smaller: if someone joined your function tomorrow, what would they need to do real work within two weeks? One page per area of responsibility, covering the stakeholders and their actual authority, what has been tried, and what a newcomer would wish they had known on day one. Terminology that fits on one screen. An escalation path people know without looking it up. That is the whole ambition.

Decay is the quieter failure, and an empty wiki page is safer than a full one. The empty page tells the reader: you need to find this out. The page last touched two years ago tells the reader: you already know this. And the reader believes it, because the page has formatting and the institutional authority of the official knowledge base.

The same team kept a library of written patterns: after every engagement, one page on the presenting symptom, the diagnosis, the intervention, and what happened. Good practice, and it worked, until someone pulled a pattern written in 2023 and applied it to a situation in 2025. The intervention was sound. The organization it assumed had been reorganized in between. The page was authoritative and wrong, which is worse than absent.

What they changed afterwards was the shelf life: every pattern got a section recording the conditions it assumes and how long those can be expected to hold. Documentation records a past observation in the present tense, and the present tense reads as fact.

The discipline for externalized knowledge is verification rather than volume. Every page carries a "last verified" date, separate from "last modified". Facts are written in the past tense with their date attached: as of January, the key stakeholder was the VP of Operations. And once a quarter, somebody asks whether any documented fact has been discovered to be wrong since last time. If the answer is always no, nobody is checking. Knowledge that is not periodically verified is not knowledge. It is a hypothesis with good formatting.

AI moved the boundary into every job

For decades this boundary moved slowly enough to ignore. AI ended that. A model can carry your documentation, write your briefings, and produce your analysis at a marginal cost near zero. Knowledge work got cheap, which raises the price of the one thing left: knowing what is actually going on and deciding what to do about it.

It also made the boundary treacherous, because the model's output reads like the product of reasoning. It names patterns and recommends priorities. What it never had is contact with your situation: it continues text, fluently, from what it has stored, and nothing in that process went anywhere near the CFO who stopped answering email in March. The output that should worry you is not the one that looks wrong. It is the one that looks finished.

The cost lands on the learning as well as the output. In 2026 Judy Hanwen Shen and Alex Tamkin, at Anthropic, ran a pre-registered experiment: 52 professional developers learning Trio, an async Python library that was new to them, half of them with an AI assistant. The assisted group hit a median of one error. The unassisted group hit three. Those errors were the learning: tested afterwards, the assisted group scored 17% lower, and the experiment found no significant productivity gain to set against it. The tool did not make them worse engineers. It removed the friction that would have made them better ones.

So the principle sharpens. On the knowledge side the model earns its keep, with one rule attached: a model touching a page counts as modification, never as verification. Only a person who went and looked moves the "last verified" date.

On the thinking side, the test runs at every desk before every delegated task: where is the judgment hiding in this? If there is none, it is knowledge work and the model is the right tool. If there is some, that part is yours, and the model's job is to assemble the material you will judge.

Every organization is setting this boundary right now, mostly by default, one delegated task at a time. Defaults favor the fluent path: leave the knowledge in heads, hand the thinking to whatever answers fastest. That is the inversion again, running faster.

The question that splits the budget

Most retrospectives ask what went wrong, which produces a narrative, a nodding room, and a list of good intentions that changes nothing. One question produces a decision instead: did we fail because we did not know what the case was, or because we could not work out what to do about it?

The first answer sends you to write something down. The second sends you to develop somebody. Ask it once and the improvement budget splits into two piles that need different money, different timelines, and different people. Ask it never and both piles get documentation, because documentation is the pile that fits inside a quarter and can be shown to a steering committee when it is done.

If you have already paid for one fix that did not hold, the useful question is which of the two failures it was aimed at. A decision brief answers that from inside the work, in two or three days: the structural constraints with the evidence behind them, and the one decision to make next. You keep the brief either way.