Knowledge Silos

Prioritize collaboration between silos.

Knowledge silos occur because of a lack of collaboration. By definition, this means that you should encourage collaboration, simply to help avoid accumulating more silos and the problems they cause. When people from different groups work together, the obviously learn from each other. However, it also helps people establish work relationships that enable them to continue to learn, even after the current task is done. Building such collaborative relationships also reduces the friction of communications between different groups, making it less likely that interpersonal issues will contribute to creating a new knowledge silo.

Treat documentation as a first-class output.

Like unit tests, documentation is often an afterthought. And also like unit tests, this is a really bad approach for long-term system stability, even though you can move faster “right now” by putting it off. Knowledge silos develop because we forget that a system’s users are not the only people interacting with it. It’s especially easy to forget one’s own coworkers. Done long enough, ignoring documentation will create knowledge silos on its own. Documentation also helps prevent organizational knowledge loss due to employee attrition. This sort of knowledge loss when someone leaves often produces siloing, as the people left behind often are overloaded with work and stuck trying to recover lost knowledge. They are certainly in no position to help others.

Fix your onboarding procedures.

Rapid growth, turnover, or both can also cause siloing, especially if your onboarding process isn’t particularly good. In particular, new people need to be able to quickly work in as much of the system as possible to avoid creating knowledge silos. While you can’t cover everything during onboarding, you want to make sure that if someone gets stuck in a particular area, that they know who to contact for help. And you need to make sure that new employees eventually do get stuck in different parts of the system. You also need to be careful here. It’s easy to tell yourself that you’ll “cross train them later”, but as new employees become more and more competent and useful, they have less and less time available to learn new things (at least in most organizations).

Increase the scope of training sessions.

When you do have training sessions for your team, it’s wise to try to open those training sessions for a broader slice of the team than you’ll think you need. This doesn’t have to include just developers – other related jobs might benefit as well. Also, by opening up training to a larger group, you are helping to reinforce the notion that understanding certain portions of the system isn’t just a task for a single team. While one team might be better at a particular set of tasks, allowing other interested parties to attend makes it more difficult for silos to form. This also helps in another way. When you have to train a broader team, you can’t make as many assumptions about what an attendee would know. This forces you to do a better job explaining, leading to better training material both for outsiders and for people going through onboarding.

Stop playing favorites or assuming that certain work is only for “elite developers”

In some environments, knowledge silos aren’t created by lack of sharing, but by management “protecting” certain groups from having to share their knowledge. While this can protect their time and attention in the short term, in the long term it means that only they can address certain issues. Additionally, members of a “favorite” team will be more reluctant to learn things from outside their team. After all, the “others” aren’t the favorites. At the very least, it will make them prioritize their own work over cross training.

Playing favorites can also increase churn, which makes knowledge silos (and knowledge loss) more likely. Note that while this sounds like it only applies to management, it’s just as true if the team believes that certain people are the only ones capable of handling certain tasks.

Communicate Proactively

When you make changes to parts of the system, you should communicate to the rest of your team, rather than just assuming that someone will ask you a question if they want to know something. While this won’t necessarily mean that everyone gets cross-trained, it does at least provide the opportunity. This practice also has another benefit, in that it forces you to document your work soon after you complete it, rather than trying to reconstruct things from memory. This will make your documentation better. Proactive communication also helps with cross-training more shy and introverted coworkers, who may be hesitant to ask questions. If you start the discussion, they are more likely to respond.

Respect the time and attention of people in other silos

While both asking for and giving help, it’s important to do so in a way that doesn’t use up an excessive amount of time or create unwanted interruptions for the other party. This tends to mean that such exchanges of information should be scheduled, timeboxed, and there should be an agenda so that both parties can get what they need with as little wasted time as possible. Do be aware though, that you probably will go off on some tangents while cross-training people and make sure that you allot extra time to allow this. These tangents can be some of the best learning opportunities you have, so do what you can to facilitate them.