No One Hoards Knowledge on Purpose. Systems Do.

TL;DR: You've started using the word "hoarder" about someone on your team. Stop. Not because the concentration isn't real, but because the diagnosis is wrong, and the confrontation it leads to will cost you the person while leaving the silo standing. Knowledge concentrates through routing loops that reward themselves; research shows concentrated ownership even looks good in the short term. Fix the routing, not the person. The playbook is below, and none of it requires an accusation.

There's a moment where a manager's private vocabulary shifts. "Priya knows that system best" becomes "Priya is a bit of a silo" becomes, one bad sprint later, "Priya hoards knowledge." Every question routes to her. The documentation never materializes. The handoff you asked for in Q1 is somehow still in progress.

You're one frustrating incident away from saying it in a one-on-one. Don't. The rest of this article is why, and what works instead.

What "knowledge hoarding" gets wrong as a diagnosis

The label describes a real pattern: critical knowledge pooled in one head, the same symptoms as any knowledge silo or pile of tribal knowledge. But it smuggles in a cause: intent. A hoarder is someone choosing to withhold. And in engineering teams, that's almost never what happened.

Watch the actual mechanism. A ticket lands. Priya fixed this system last, so she's fastest, so it's assigned to her. She fixes it; her expertise deepens; the next ticket routes to her even faster. Questions follow the same gradient: why wait a day for someone else to figure it out when Priya answers in five minutes? Every one of those routing decisions was locally correct. Nobody withheld anything. The moat dug itself while the team applauded the efficiency.

Why the loop gets rewarded (this is the uncomfortable part)

Bird et al.'s "Don't Touch My Code!" studied ownership in Windows Vista and Windows 7 and found that components with more low-expertise contributors had more pre-release faults and post-release failures, while a higher ownership share for the top owner correlated with fewer. Read that carefully: in the short term, concentration is rewarded with quality. The loop doesn't just run unchecked; it runs applauded, right up until the day it converts into key-person risk with a notice period attached.

Meanwhile the team pays daily. In the 2024 Stack Overflow survey, 45.2% of developers agreed knowledge silos keep ideas from crossing the organization, and 30% said silos hit their productivity ten-plus times a week. And your "hoarder" is usually the most generous person on the team - the one answering every DM. Answering is faster than teaching, so every helpful answer deepens the dependency it resolves.

Why the accusation backfires

Confronting the person as a hoarder does three things, all bad. It punishes your most load-bearing engineer for a topology they didn't design. It teaches the team that deep expertise is a liability, which is precisely backwards. And it corrodes the person's trust right when their leaving would hurt most.

One honest caveat: deliberate withholding does exist. Almost every time, it's downstream of an incentive the org created: someone who learned they're only valued for being irreplaceable, or who's quietly afraid of what redundancy means for them. That is still a system to fix, not a person to prosecute. Make sharing the rewarded behavior and the withholding usually dissolves. If it doesn't, you have a management conversation. Have it about the incentive, with receipts.

How to spread knowledge without a trial

All free, starting this week:

1. Reroute questions before you reroute people. Area questions go to a channel, not a DM. The expert still answers - publicly, searchably, once.
2. Put a rotating second reviewer on the concentrated areas. Bacchelli & Bird found code review's real outcomes lean toward knowledge transfer and team awareness. It's the cheapest transfer channel you have, and it works on live code instead of producing docs nobody reads.
3. Route the next two tickets in the area to someone else, with the expert navigating instead of typing. Slower this sprint, redundant by next quarter; the full menu is in how to reduce bus factor.
4. Make sharing count. If teaching, pairing, and docs are invisible in your recognition system, you're paying for the silo you're angry about. (This is glue work, and it's chronically unrewarded.)
5. Run the acceptance test: the expert takes two weeks off and nobody messages them. Until that's true, the system - not Priya - still owns the problem. A structured way to get there is the ninety-minute drill.

Seeing concentration before it earns a nickname

The bitter part of the hoarder story is that it's always told late: the word only comes out after the moat is deep. The concentration itself was visible in git history for months: one name on most meaningful changes in an area, one reviewer waving everything through, the whole trajectory written down in commits.

Busfactor computes that map continuously (authorship-weighted, review-aware ownership per area) and flags where knowledge is pooling while spreading it is still a routing tweak rather than a quarter-long project. The honest limits: the map shows concentration, never motive. No tool can read intent, and none should pretend to. And knowledge that never touches the repo (Slack answers, pager lore, vendor quirks) is invisible to git; the map tells you where to look, and the conversation does the rest. What it will never be is a leaderboard: this is about protecting the person carrying the load, not scoring them.

The door

Retire the word "hoarder" this week - in your head first. Then do the two cheapest things on the list: reroute the questions, add the second reviewer. If you want to see every area where knowledge is quietly pooling - with receipts, before it becomes a due-diligence finding - connect your repos and look at the map. The person you were about to blame will be the most relieved when you do.