Every engineering organization has them.
The people everyone goes to before making an important decision.
Need to understand a legacy system?
Ask Sarah.
Need to know why the networking stack works that way?
Ask Mike.
Need to determine whether it's safe to migrate a database?
Talk to Priya.
We usually call these people 10x engineers.
I think that's often the wrong diagnosis.
They're not 10x engineers.
They're carrying 10x more organizational knowledge than everyone else.
And that's a very different problem.
Engineering organizations tend to celebrate hero engineers.
They're the ones who:
They're incredibly valuable.
They're also evidence that the organization has become dependent on individual memory.
If every important decision requires the same handful of people, your organization doesn't have distributed engineering judgment.
It has centralized cognition.
That doesn't scale.
When people describe exceptional engineers, they often focus on technical skill.
They're brilliant.
They know distributed systems.
They understand networking.
They've seen everything.
Those things matter.
But after twenty-five years in engineering, I've become convinced that's not what makes them indispensable.
What makes them valuable is context.
They know:
Most of that knowledge isn't in the repository.
It's in their head.
Organizations often try to reduce dependence on senior engineers by hiring more engineers.
That helps.
But it doesn't solve the underlying issue.
Knowledge isn't replicated by adding people.
It's replicated by making reasoning durable.
The goal shouldn't be fewer senior engineers.
It should be fewer decisions that require exclusive access to one person's memory.
If one engineer maintains a critical service on their laptop without version control, we'd recognize that as unacceptable.
Yet organizations routinely allow critical architectural knowledge to exist only in conversations, Slack threads, and memory.
We accept a level of operational risk for reasoning that we would never tolerate for software.
That's strange.
The consequences are just as real.
Large language models make this challenge more visible.
An AI can read every source file in minutes.
It can summarize architecture diagrams.
It can analyze telemetry.
What it can't recover is reasoning that was never captured.
Why did we reject this design?
Why did we split this service?
Why was this database denormalized?
Those aren't implementation questions.
They're judgment questions.
Without that context, AI becomes another engineer asking the same senior people everyone else depends on.
Software begins as source code.
Then it's compiled into something executable.
Engineering organizations rarely perform the equivalent step for knowledge.
Ideas remain scattered across:
The organization never compiles those fragments into durable understanding.
The result is predictable.
The same questions are answered again and again.
Whenever this topic comes up, someone inevitably says:
So we need better documentation.
Not exactly.
Documentation tells you what the system is.
Compiled knowledge tells you:
Those are different artifacts.
One describes a system.
The other teaches judgment.
We often measure engineering maturity by:
Those are useful indicators.
I'd add another.
How much of your organization's engineering judgment survives when your most experienced engineer goes on vacation?
Or leaves the company.
Or retires.
If the answer is not much, then your greatest engineering asset is also your greatest operational risk.
The best engineering organizations don't eliminate experts.
They multiply them.
Not by asking senior engineers to answer more questions.
By making every important answer durable enough that the next engineer starts from understanding instead of archaeology.
That's what good engineering has always done for software.
The next frontier is doing it for engineering judgment itself.
Because your best engineers shouldn't be bottlenecks.
They should be the people who teach the organization how to stop depending exclusively on them.