Rare knowledge doesn't feel rare

Nobody can hand you a list of what only they know. Knowledge transfer before an engineer leaves starts in your own systems: they already record who to ask.

Share
Rare knowledge doesn't feel rare
Rarity is a fact about everyone else, not a feature of the knowledge itself. From inside one head every item looks the same, and that is the view everyone has. Counting who else holds each one is what would rank them, and that is the view nobody has.

Nothing in what you know marks who else knows it.

So nobody can sort their own knowledge by rarity from memory, and what surfaces when they try is whatever is easiest to recall. The person holding the rare thing can't hand you a list, and can't tell that they can't.

A long-lived system holds three versions of that blindness. The people who made the original decisions no longer remember which ones they chose and which arrived with the defaults. Ask the engineers who joined later and they will tell you how the system behaves, which is also what everyone around them says, so it registers as common knowledge. And what is running reads as a decision to whoever operates it, because someone had to type it.

Three maps, each drawn from inside one head, all of them showing what was decided and by whom, and no vantage from which to check any of them. All of that is already true before anyone leaves. The last departure makes it permanent.

What a decision leaves behind comes in three parts: the value, the reason it is right, and the condition that has to hold for the reason to work. The value is always there. The reason is there when somebody wrote it down. The condition is the easiest part to omit.

Nothing turns a last day into a work item

An hour with the person who knows competes for time against problems that can point at something failing. A last day sits on a calendar. What that person is the last to explain is spread across a system nobody has joined to it, so the backlog sorts by whatever has a symptom.

From outside, it looks like someone burning a senior engineer's afternoon on questions with obvious answers, and most of the questions do have obvious answers. That part is the method working. The waste is the other kind, a question you could have settled yourself against a document you never read. An hour holds only so many questions, and every one spent on a lookup is one that never gets asked.

So order the hours by person, and take the first candidates from the history instead of asking around. The code that has not changed in years carries the name of whoever wrote it, and of whoever has touched it since. Neither name proves anyone remembers. Both are places to start.

None of this needs a map of who knows what, because no such map exists. The history is not a map. It is a record of who was there, which is enough to open with. Sit with the names that come back. Whether anything on that surface is theirs alone is what the hour finds out.

Waiting for a resignation is already too late. Departure only sorts a queue that was there years before anyone gave notice.

The prompt has to come from outside the memory you are trying to reach

The knowledge is still in their head. Searching for it is the part that fails.

So search from the outside. Put something in front of them and ask about that. A function nobody has touched in six years, a configuration file, a design document from two rewrites ago. Any kind of object will do, as long as the prompt comes from somewhere other than their own sense of what is worth mentioning, because that sense already failed once.

"What do you know about this system?" asks them to search their memory with no ranking key. There is no way to know when that search is finished, and it produces a document you have read before. The question that works points at something: why is this one what it is. That hands them an object and lets recognition do the retrieving.

Recognition is cheap. The expensive part is finding what is worth recognizing, and that asymmetry is the trade. You spend your own hours in the repository so the hour you booked with them is all recognition.

The strongest objects are the ones that read wrong. A function that scans plainly and does something nobody would design on purpose is already a question, and you do not have to phrase it.

Two answers close a question that is still open

Most answers come back in seconds. Two of them are traps. "That's how it shipped" closes the question the way an answer does, and it isn't one. It tells you where the value came from. What you need is whether it still fits here, and nothing upstream settles that.

The second trap is fluency. Put an object in front of someone and it will pull a reason out of them whether or not they ever knew one, and an assembled reason arrives with the same confidence as a remembered one.

You will not settle which one you got, and you do not have to. What you came for is an explanation that still holds, and the behavior and the records can establish that without establishing who once believed it.

The answer worth the hour is the one no lookup could have given you.

What you can point at bounds what you can recover. The decision that never touched the system leaves nothing to point at: an approach abandoned before anyone built it, a failure mode avoided early enough that nothing records the swerve. There is no object, so there is no question to ask, and no hour with anyone reaches them.

A record that can't expire isn't durable

A written reason outlives the condition that made it true. A timeout is set short, and a comment beside it says the call it guards is fast. That is the value and the reason, and it is everything the file holds. What the file does not hold is the condition the reason rested on, which is that the call never leaves the host. While the call stays local, that fact is not a condition anybody notices. It is just where things run.

The third part is what the whole hour is for. The first two you can read. Nothing in the file points at the third, so you have to ask for it, and the question has a second step in it.

Write up the first two and you have written the artifact you already had. The next person to read it starts where you started, an hour of someone's time later. And a justification can't tell you it has expired either. The text stays exactly as it was typed, describing a world that has since moved.

A condition is a claim about the world, so the world can contradict it. Write down what you got for whoever reads it next, and turn the condition into a check. Then the reason stops depending on anyone remembering it exists. That holds while the check can still see the condition, and only if it fails loudly when it cannot.

Not every reason bottoms out in something a check can watch. A slow link between two sites is a measurement, and a threshold on it is a condition. Not trusting a new route is a judgment. It becomes a condition only when somebody states what would settle it: how many hours in production, which version, how much traffic moved across. A judgment nobody can state that way stays a written decision, with all the decay that implies.

Where the condition lives nowhere but in memory, the last departure takes it. The value is still there to read, the reason may be too, and the condition the reason rested on is gone. Change the value, watch what breaks, and you learn only that nothing objected under the conditions you could reproduce. The system keeps the number and loses the only thing that could have retired it.