There is a phrase we sometimes use at work that sounds like the ultimate compliment:
I don’t know what we’d do without you.
I’ve said versions of it myself.
Usually, we mean it positively. This person knows the system. They understand its history. When something breaks, they know where to look. When a difficult decision needs to be made, everyone wants them in the room.
They are invaluable.
But over the years, I’ve learned to hear something else inside that sentence.
Dependency.
Because there is an important difference between having highly valuable people and building an organization that cannot function without particular people.
The Holiday Test
Here’s a simple test.
Think about one of your most important teams.
Now imagine that its most experienced person goes on holiday tomorrow for three weeks.
Not resigns.
Not disappears permanently.
Just takes a perfectly normal holiday.
What happens?
Can the team still make important decisions?
Can somebody understand why a previous architectural choice was made?
Can another engineer diagnose the production system?
Can another team find the information they need without messaging the person who’s away?
Can work continue?
Or does the organization quietly begin accumulating questions for when that person returns?
That tells you something about your architecture.
“Ask David”
Most experienced organizations have some version of this.
Why was this designed this way?
Ask David.
How does that integration actually work?
Ask David.
What happened the last time we changed this?
David will know.
Can we safely change it?
Let’s wait until David is back.
David may be brilliant.
But David has also accidentally become a database.
A search engine.
An architectural decision record.
An integration manual.
And sometimes an approval workflow.
The problem isn’t David.
The problem is everything the organization has decided not to make persistent because David remembers it.
We Wouldn’t Design Software This Way
My instinct as a software architect is to look at this differently.
Imagine designing a distributed system in which every important request had to pass through one component.
That component possesses critical state unavailable elsewhere.
Other components cannot continue when it becomes unavailable.
And there is no reliable recovery mechanism.
We would identify the risk immediately.
Single point of failure.
Yet organizations regularly build exactly this architecture around people.
One manager becomes the route to another department.
One engineer carries years of architectural context.
One product owner understands why dozens of decisions were made.
One operations person knows how to recover the system.
And because these people are exceptionally capable, the architecture can appear to work remarkably well.
Until it doesn’t.
Competence Can Hide Fragility
This is what makes the problem particularly interesting.
Sometimes your strongest people are unintentionally hiding your weakest systems.
They compensate.
They remember.
They connect people.
They answer questions.
They notice problems before anyone else.
They fill gaps in documentation.
They recover context.
They know whom to call.
The organization sees performance.
What it may not see is the extraordinary amount of human routing required to produce that performance.
This connects directly with something I wrote about recently: Visible Progress Sits on Invisible Work.
Sometimes that invisible work is concentrated inside a handful of highly capable people.
And eventually, the cost appears.
When Expertise Becomes a Queue
Once too much knowledge accumulates around one person, requests begin routing toward them.
At first:
Can I quickly ask you something?
Then another.
And another.
Eventually, their day becomes a queue.
They attend meetings because their context is required.
They review work because nobody else feels sufficiently confident.
They answer questions because documentation doesn’t contain the reasoning.
They approve decisions because ownership hasn’t spread.
Ironically, the more valuable they become, the less time they have for the work that made them valuable in the first place.
The expert becomes the bottleneck.
And everybody loses.
The Answer Isn’t to Remove Experts
This is important.
The solution isn’t to make everybody interchangeable.
People aren’t servers.
Experience matters.
Judgement matters.
Deep expertise matters.
Some people will always know more about particular areas than others.
That’s healthy.
The architectural question is different:
Does expertise increase the capability of the system, or increase dependency on the expert?
A great senior engineer who helps five engineers make better decisions has increased system capability.
A great senior engineer who must personally make every important decision has increased dependency.
Those may look similar in the short term.
At scale, they produce completely different organizations.
Make Decisions Persistent
One practical place to start is decisions.
Important decisions shouldn’t disappear when a meeting ends.
Capture:
- What did we decide?
- Why?
- What alternatives did we consider?
- What assumptions influenced the decision?
- Who owns what happens next?
This doesn’t require enormous documents.
Often a short, well-structured decision record is enough.
The objective isn’t documentation for documentation’s sake.
It is persistence.
Someone who wasn’t in the room should be able to reconstruct enough context to move forward.
Share Context, Not Just Conclusions
Another common failure is transferring the answer without transferring the reasoning.
An experienced person says:
Don’t change that.
The junior engineer complies.
Problem solved?
Not really.
Next time, the junior engineer still needs the expert.
A stronger interaction is:
Don’t change that yet. Here’s the dependency you can’t see, here’s why we designed it this way, and here’s what would need to change before that constraint disappears.
Now knowledge has travelled.
The next decision may no longer require the same routing.
That’s how expertise begins strengthening the system.
Distribute Ownership
Ownership works similarly.
If every significant choice travels upward, managers eventually become routers.
If every technical decision travels toward the most senior engineer, technical leaders become queues.
If every customer question travels toward one product expert, that person becomes an API everyone depends on.
Healthy systems distribute decisions to the lowest sensible level while making boundaries clear.
People know:
- What can I decide?
- When should I involve somebody else?
- Where is the relevant context?
- Who owns the outcome?
That combination creates autonomy without chaos.
Design for Someone to Be Missing
There’s a practical design principle I’ve come to value:
Assume someone important will be unavailable.
Because eventually they will be.
Holiday.
Illness.
Training.
Parental leave.
A conference.
Another project.
Or simply a day when they need uninterrupted time to do meaningful work.
A resilient organization shouldn’t require its best people to remain permanently reachable.
That’s not resilience.
That’s dependency disguised as commitment.
The Better Compliment
Perhaps we need a better way to recognise our strongest people.
Instead of:
Nothing works without you.
Imagine being able to say:
This organization works better because of what you built into it.
People make better decisions because you shared your judgement.
Others understand the system because you transferred context.
Teams operate independently because you clarified boundaries.
Problems get solved without you because you helped others learn how to solve them.
And when you take three weeks off?
Work continues.
That doesn’t make you less valuable.
It may be one of the strongest demonstrations of your value.
Because:
Your best people should strengthen the system. They should never have to become the system.