I spent six weeks trying to move knowledge out of one person's head. It didn't move.

A company called me in this spring with a question that sounded technical.

Their core product is around thirty years old. It runs a part of their clients’ operations that has to be right — get it wrong and it shows up in someone’s pay. The engineer who designed it is approaching retirement. The question was whether AI tooling could lower the barrier enough that other developers could take over work that had, until now, required years of familiarity with a codebase written in a language most developers have never touched.

The answer is yes. That part worked, and I’ll come back to it, because it matters less than what happened alongside it.

What I actually spent six weeks discovering is that the hard part isn’t the language. It’s that in most organisations, knowledge only moves when the person who holds it solves the problem — and solving is the one activity that transmits nothing.

What I set up

I picked a real feature. Not a demo, not a toy — a genuine piece of work the business needed, with real consequences if it were wrong.

Then I ran what I thought was a reasonable transfer loop. I’d build a version. I’d send it to the expert. He’d review it, tell me what was wrong, and I’d revise. The idea was straightforward: over enough rounds, the reasoning behind his corrections would end up in my head, and from there into a document, a test, a piece of tooling — somewhere other than him.

I want to be clear about the conditions, because they were about as favourable as they get. He was willing. Nobody was protecting territory. He wasn’t being asked to do this in addition to a full workload as an afterthought — it was understood to be part of the engagement. And he’s good, which is the whole reason the exercise was worth running.

What he actually did

This is the part I want to put on the record, because it’s what makes everything after it credible.

He didn’t skim what I sent and reply with notes. He built his own test project. He compiled it. He ran the calculation interface himself. He checked individual results by hand, and told me, accurately, that doing so was tedious because the system makes it hard to construct historical cases to check against.

When my code crashed, he didn’t send me a stack trace. He reproduced it, traced the cause, disabled the offending section, re-ran the job, confirmed it completed, and then wrote it up.

He proposed the correct architecture, which I adopted unchanged.

Then he came back the next day, unprompted, with an additional observation about how many times the code was reading from the same table when once would do.

Every correction he made was right. Not defensible — right.

The part that stopped me

At the end of six weeks, the person who understood that feature best was still him.

Not because he’d withheld anything. Because of the shape of what came back.

I sent out a problem. What returned was a solution. Correct, well-reasoned, often better than what I’d have arrived at — and complete. A finished answer, with the reasoning that produced it compressed inside it, in a form I couldn’t unpack.

I had learned that my approach was wrong. I had not learned why his was right, in a way I could apply to the next problem.

The knowledge moved in the wrong direction. It came to him, was resolved, and went back out as an artefact.

What was actually happening

It took me longer than it should have to name this properly, because the obvious explanations are all wrong.

It isn’t reluctance. He was more engaged than most people would be.

It isn’t a communication problem. His written explanations, when they came, were excellent — I’ll get to that.

It’s this: solving a problem and transmitting how you solved it are two different activities, and they compete for the same hour.

I’ve been circling this for a long time — I wrote about corporate memory back in 2009, before I had a way to say it. This engagement is the first time I watched the mechanism directly.

Solving is fast, satisfying, and closes the thing. Transmitting is slow, less satisfying, and while you’re doing it the problem stays open in front of both of you. Anyone who genuinely enjoys solving will, in good faith and every single time, go to the solution. It’s not a failure of generosity. It’s the trait that made them worth asking.

Twenty-five years of that accumulates an extraordinary amount of knowledge in one head. Not through hoarding. Through appetite.

Which means the standard fix — ask them to write it down — is aimed at the wrong thing. It treats an appetite as an attitude. He’d agree to it, sincerely. Then a real problem would arrive, and he’d solve it, because that’s what he’s for.

The thing that made it obvious in hindsight

Here’s what I noticed when I went back through the correspondence.

He had already written it all down.

Not in documentation. In his replies. Three emails from one month contained, in detail and unprompted, exactly the knowledge I’d spent six weeks trying to extract: why a rule anchored to the month breaks a model that assumes a fixed offset. Why a particular optimisation exists at all — because without it the job used to run for hours. Which key convention the existing tables follow and why breaking it would cost something.

None of that is in the code. None of it is in any document. All of it is in his email, written fluently, because someone asked him a specific question and answering specific questions is something he enjoys.

The knowledge wasn’t stuck. It came out easily. What was missing was anyone whose actual job was to ask, and to keep what came back.

What I recommended instead

Not a documentation project. Not a scribe.

Give someone the explicit role of bringing him problems. Not observing him, not interviewing him — bringing real work, sitting with him while it gets solved, and writing down afterwards why it was solved that way.

He continues doing exactly what he’s good at, at full speed. The capture happens on the other side of the desk, and from his side it’s largely invisible. He’s not being asked to change how he works, which is fortunate, because a way of working that has been productive for twenty-five years isn’t going to change on request.

Two conditions make it work or fail. The role has to be framed as help with his problems, not as preparation for his succession — the wording matters as much as the arrangement. And the choice of person matters more than their seniority; what’s needed is someone with the technical judgment to understand what they’re hearing, the curiosity to want to, and a working relationship that makes the whole thing plausible.

The part I owe you, about the AI

The tooling did work. Developers who aren’t specialists in that codebase closed real tickets in it during the engagement, and kept doing so after I left, on their own initiative. The barrier to entering an old, large, unfamiliar system has genuinely dropped, and that’s a bigger deal than it sounds — it changes who can be considered for a succession like this one.

But here’s the finding that ties the two halves together.

The code the tooling produced compiled cleanly and passed its entire test suite. It was also wrong in five separate places, and every one of them was found by the same person — the one who knew why the system was built the way it was.

None of those five were detectable by a compiler or by a test. Each required knowing the history: which business rule the design was accommodating, which past performance problem an odd-looking optimisation had been built to solve.

Verified is not the same as validated. The tests confirmed the code did what it said. Only someone with the history could tell you whether what it said was the right thing.

Which is why the succession problem was never really about the language. The language barrier came down. The other one — knowing why the system is the way it is — didn’t move at all, and it’s the one that determines whether any of this survives the retirement.