The Knowledge Hoarders: When Workplace Culture Goes Toxic
Been scrolling through some workplace discussions lately and stumbled across something that really struck a nerve. Someone was asking about knowledge hoarding at work - you know, those colleagues who seem friendly enough on the surface but somehow never quite share the information you need to actually do your job. The responses that followed painted a picture that’s unfortunately all too familiar in the tech world.
The original poster described starting at a new company where there’s a suspicious lack of documentation and sharing. People appear friendly but won’t provide the actual know-how needed to get things done. Sound familiar? If you’ve worked in tech for more than five minutes, you’ve probably encountered this phenomenon.
What really got me thinking was the range of experiences people shared. One person mentioned being told their code didn’t meet standards, but when they asked for those standards, they were refused. Imagine that - being expected to follow rules that nobody will tell you. Another talked about being told to do things “the right way” without any documentation of what that way actually was. It’s like being asked to play a game where nobody tells you the rules, then getting penalised for not knowing them.
The psychology behind knowledge hoarding is fascinating and frustrating in equal measure. Some people genuinely believe that keeping information to themselves makes them indispensable. They think that if they’re the only one who knows how the legacy system works or where the important files are stored, they’ll survive the next round of layoffs. It’s a defensive strategy born from insecurity and, let’s be honest, a pretty misguided one.
Working in DevOps, I’ve seen this play out countless times. There’s always that one person who’s been there forever, who knows exactly how the deployment pipeline works but has never written any of it down. They become the bottleneck for everything, and God help you if they go on holiday or, worse, leave the company. Suddenly you’re left trying to reverse-engineer years of tribal knowledge from cryptic comments in config files.
But here’s the thing that really frustrates me about knowledge hoarding - it’s ultimately self-defeating. One commenter made an excellent point about how hoarding actually makes you more likely to be made redundant, not less. Companies eventually get sick of having single points of failure. They’ll either move away from whatever system you’re hoarding knowledge about, or they’ll simply accept the short-term pain of losing you to avoid the long-term headache of being held hostage by one person’s unwillingness to share.
The counter-argument some people make is interesting though. During times of high redundancies, holding onto specialised knowledge can be a survival strategy. If you’re the only one who knows how to keep the revenue-generating system running, you might buy yourself some job security. It’s cynical, but there’s a grain of truth to it.
However, this completely misses the bigger picture. Knowledge sharing isn’t just about job security - it’s about building better teams, better products, and better companies. When I work with teams that actively document their processes and share knowledge freely, the difference is night and day. Problems get solved faster, new team members can contribute sooner, and everyone benefits from collective wisdom rather than individual gatekeeping.
The environmental impact of knowledge hoarding is something we don’t talk about enough either. When teams can’t share knowledge effectively, they waste enormous amounts of time and resources. People duplicate work, reinvent solutions that already exist, and burn through computing resources on inefficient approaches because they don’t know better methods exist. In an industry already grappling with its carbon footprint, this kind of waste is particularly galling.
Not all knowledge hoarding is malicious, of course. Sometimes it’s just a symptom of poor processes and time constraints. Writing good documentation takes time, and that time is rarely recognised or rewarded in performance reviews. It’s much easier to get credit for shipping new features than for documenting existing ones. This creates a vicious cycle where the people who would document things properly simply don’t have the incentive to do so.
The solution isn’t simple, but it starts with leadership recognising that knowledge sharing is a core business function, not a nice-to-have. Companies need to reward documentation and mentoring just as much as they reward individual contributions. They need to build time for knowledge transfer into project timelines and make it clear that hoarding information is actively harmful to the team.
From a personal perspective, I’ve learned to be wary of workplaces where knowledge hoarding is tolerated or even encouraged. It’s usually a sign of deeper cultural problems - lack of trust, poor leadership, and short-term thinking. These places tend to burn through good people while rewarding the kind of behaviour that ultimately damages everyone.
The good news is that the tide seems to be turning. Younger developers, in particular, tend to be much more collaborative in their approach. They’ve grown up with Stack Overflow, GitHub, and a culture of open-source sharing. They expect documentation to exist and aren’t shy about creating it when it doesn’t.
Moving forward, I think we all have a responsibility to push back against knowledge hoarding wherever we encounter it. Document your own work obsessively. Ask for documentation when it doesn’t exist. Share knowledge freely and publicly praise those who do the same. Call out hoarding behaviour when you see it, but do so constructively - help people understand that sharing knowledge makes everyone stronger, not weaker.
The tech industry has always been at its best when it embraces collaboration and openness. Knowledge hoarding is the antithesis of those values, and it’s up to all of us to ensure it becomes a relic of the past rather than a feature of our future workplaces.