We like breakthroughs to have names attached to them.
It makes history easier to remember. Instead of carrying a network of experiments, arguments, failed attempts, technicians, institutions and incremental improvements, we attach the change to a person. Someone invented this. Someone discovered that. Someone saw what everybody else missed.
Sometimes that's reasonably accurate.
It's rarely the whole story.
Even when an idea really does begin with one person noticing something unusual, there's a considerable distance between having the insight and making it available to everyone else. Someone has to test it. Someone has to describe it well enough that another person can reproduce it. Tools have to be built. Mistakes get discovered. Other people modify the original idea, sometimes in ways its originator dislikes.
Eventually, if the thing is useful enough, people stop needing to know much about the person who started it.
I've come to think that's an interesting stage in the life of an idea.
The person still matters. Attribution matters too, especially when careers, compensation or historical understanding depend on knowing who actually did the work. There's no particular virtue in erasing somebody from their own contribution.
Still, attribution and dependency are different things.
I can know who designed something without requiring that person to remain available every time I use it. In fact, one of the clearest signs that knowledge has become transferable is that somebody else can pick it up, understand enough of it to proceed, and eventually do something the originator didn't anticipate.
Software provides an unusually visible example.
I've written systems that worked perfectly well as long as I was the person operating them. I knew why a strange configuration existed. I remembered which service needed to restart first. If something behaved unexpectedly, I could reconstruct the history that produced it.
From my perspective, the system was understandable.
Then someone else had to use it.
Suddenly the things I had been carrying in my head became part of the architecture.
That doesn't mean the original design was bad. During early development, keeping some knowledge in one person's head can be extraordinarily efficient. Writing documentation for something that will change tomorrow may waste more time than it saves. A small project can move quickly because two people share context that would take fifty pages to explain formally.
The problem appears when temporary dependence becomes permanent without anybody noticing.
If the project grows while the knowledge required to operate it remains attached to particular people, their expertise becomes both valuable and dangerous. They can't easily leave. Other people become reluctant to change what they don't understand. Decisions accumulate around whoever remembers why the last decisions were made.
Eventually everyone knows that Alice is the only person who understands the billing system.
Alice would probably like a vacation.
This is where transferring knowledge begins to matter more than preserving the original arrangement.
Some of that transfer happens through documentation and training. Some happens through interfaces that make internal complexity unnecessary for ordinary use. Tests preserve expectations. Standards let independently built components interact. Naming conventions reduce the number of private agreements people have to remember.
None of those things contains the full intelligence of the people who built the system.
They don't need to.
They preserve enough of it for someone else to continue.
Something similar happens outside technology. A skilled craftsperson teaches an apprentice, who copies the technique imperfectly at first and eventually changes it. A newsroom develops practices that allow a reporter to leave without taking the newspaper's institutional memory with them. A family recipe survives because somebody finally writes down approximately wh