This post is mostly a reflection on Addy Osmani’s chapter about knowledge silos and how it connects with situations I have seen, and sometimes reinforced, myself.

When one person becomes the queue

In data and platform work, knowledge silos rarely announce themselves dramatically. More often they arrive dressed as responsibility.

One person knows the ugly Airflow DAG nobody wants to touch. Another knows why a Snowflake policy was written in a strange way three quarters ago. A third knows which operational step is safe to automate and which one still has a sharp edge.

At first this can look like efficiency. Questions go to the fastest person. Incidents get resolved quickly. Reviews move because the “owner” already knows the answer.

I have been on both sides of this. I have depended too much on the one person who knew a system well, and I have also been that person, quietly becoming the routing layer for every question touching an area I understood better than the rest of the team.

The problem is that this arrangement feels efficient.

Right up to the point when it very clearly is not.

I’m not even sure I noticed this happening at the time — it just gradually became normal.

Why it happens

I do not think knowledge silos are always about ego or job protection. Sometimes they are. But in my experience the more common cause is simpler.

It starts when a system is messy, production-facing, or expensive to get wrong. The person carrying the operational risk stays close to it. They know the history, the failed attempts, the hidden dependencies, the weird edge cases.

Handing that context over takes time they do not feel they have, so they keep moving alone.

That choice is understandable. It is also how the silo gets stronger.

I have seen this happen in small engineering teams where everybody is busy and the shortest path is obvious: let the person with context handle it. For a sprint or two, that can even be the right call.

The trouble starts when a temporary shortcut turns into a default operating model.

Then the signals show up.

Code review can become a bit ceremonial, because only one reviewer can really judge the change.

Vacation creates low-grade anxiety because everyone knows which system must not break that week.

Important decisions start living in somebody’s head, or in Slack threads nobody will realistically find later.

And the person who “owns” the area slowly becomes overloaded by support, interruptions, and invisible maintenance.

What I had to admit

The uncomfortable part for me is that being the person with the context can feel good.

People trust your judgment. You can move quickly. You know where the bodies are buried. In the short term, it can look like competence.

In the long term, it often becomes a limit on your own effectiveness.

If every tricky issue in a certain area still needs me, then I have not really scaled anything. I have just built a nicer bottleneck.

That is the part I try to keep in mind now. Not because sharing knowledge is morally better.

Because it is operationally better, and because the alternative quietly traps both the team and the so-called expert.

What has helped in practice

I do not think this gets fixed by saying “we should document more” and leaving it there. The useful version is more concrete.

What helped me most was lowering the bar for transfer.

A short runbook is better than waiting for the perfect document.

A pairing session on a real incident is better than a polished presentation nobody will revisit.

A review where I explain why a change is risky is better than leaving a vague “not comfortable with this” comment and keeping the reasoning to myself.

I remember one case where a single Snowflake policy change was blocked for days just because only one person felt comfortable touching it.

I have also learned that ownership spreads faster when the second person is allowed to do real work, not just observe.

If someone only watches me handle the difficult part, I still own the system.

If they take the next change with me nearby, the center of gravity already shifts.

In teams I led or supported, the most useful small changes were usually these:

• asking for one more reviewer outside the usual ownership line
• rotating small operational tasks before rotating the big scary ones
• turning recurring Slack answers into notes immediately (this one helped more than I expected)
• involving another engineer in incident follow-up, not only in the incident itself

None of this is glamorous. That is probably why it gets postponed.

The real payoff

People sometimes act as if sharing knowledge makes you replaceable. I think the opposite is closer to the truth.

The engineer who keeps most of the context often becomes necessary in a very narrow way.

The engineer who spreads context becomes useful at a broader level.

That second version has more room to improve systems, mentor others, and take on work that actually requires senior judgment instead of constant re-explanation.

After seeing this play out many times over the years, I’ve learned to trust that pattern more than the short-term comfort of being the only one who understands something.

One question I try to use

When I notice myself holding onto an area too tightly, I try to ask a very simple question:

What part of this is genuinely hard, and what part is just undocumented history living in my head?

That question does not solve the problem on its own.

But most of the time it at least tells me where to start.

If the hard part is real, I should teach it.

If the hard part is mostly history, I should write it down and stop making the team rediscover it through me.