Avoid Knowledge Hoarding in Software Development Teams

A familiar character in the dysfunctional dev team is the knowledge hoarder.

An individual who knows a lot about your software and architecture, but for one reason or another, generally because of purported complexity or time constraints, cannot share this knowledge with others.

Developers and the non-technical alike will defer to this individual because they know the answers to the questions to get stuff done.

While this character may only ‘appear’ to be holding up the dev team, they are almost certainly holding it back.

Identifying the Knowledge Hoarder is Easy

Got a dev that can't go on holiday because he holds too much important information? Or find that when they go on holiday all work slows? They are likely to be your knowledge hoarder.

The Dangers of Knowledge Hoarding

By allowing a knowledge hoarder in your team, you create a bottleneck. All work must flow through it, and the rest of your team can only work as fast as that bottleneck allows. This limits the amount of work you can get out of the door.

The knowledge hoarder will be in a position of great power in your team, capable of making or breaking your business. Even if this is not at the forefront of the hoarder's mind, it will be in the back.

By virtue of knowing the most, the knowledge hoarder will almost certainly be working unchecked and unquestioned. Meaning that they are probably causing as many problems as they fix, and further compounding the unusual power dynamic.

The Causes

Knowledge hoarding is, more often than not, caused by one or a combination of the following;

1. Overcomplicated software.
2. A lack of automation, workflow, and process.
3. A lack of transparency.
   

To prevent knowledge hoarding. You must address these problems.

The Cure

First, make sure every part of your development process is documented in detail.

From start to finish, no matter how complicated. Every step, every switch, and action needs to be compiled and written down. This gives you the beginnings of transparency.

From here, you can start looking at where you can apply automation using standardised, documented techniques.

You are aiming for the kind of automation that any developer can run without requiring a specialism or years' worth of experience. This begins to alleviate your bottleneck.

Overly complex software tends to be very hard to automate.

If you have software that can not be automatically built and shipped because it is too complicated, you almost certainly have software that is hard to maintain and work with; you need to simplify it.

Reduce the complexity and automate build and deploy processes.

Then iteratively rinse and repeat. By doing this, you are removing the conditions under which a knowledge hoarder can thrive, improving the reliability of your team's work and increasing its capacity.

It's remarkably easy to fall into a situation where Knowledge Hoarding can occur and often incredibly difficult to climb back out of the pit. Therefore it's of the utmost importance that development teams are monitored and mentored as a preventative measure.

But by following the ideals of transparent working practice, automating everything and keeping everything as simple as possible, you go a long way in preventing such trouble.