Knowledge silos are very common in professional software development environments. They are a natural phenomenon caused by a variety of situations. Company mergers and acquisitions are one source of them. Another source is just having separate teams working on entirely separate projects, that suddenly have to integrate. Knowledge silos can also be created when a company goes through a period of strong growth or decline. Regardless, knowledge silos are something you will encounter to some degree in every workplace.
It’s worth your while to do what you can to attempt to break down knowledge silos when you see them. Not only do knowledge silos often create extra work, they can cause subtle errors, and even make it difficult to evolve your software to deal with changing conditions in the market (including regulatory ones). Knowledge silos also reduce the resilience of your organization as a whole, making you dependent on a small subset of your team for critical functionality. Even worse, they can also introduce an “us vs them” dynamic in teams that would otherwise work well together, as the blame for problems is always in the “other dude/chick’s code”.
Knowledge silos are difficult to break down. You’re not going to be able to do it in a day, nor are you likely to be able to do it during someone’s two week notice period. Rather they generally have to be disassembled over time, while other work is still getting done. It requires time, because it’s exactly the same kind of exploration of a new system that occurs when a new employee is hired. It’s essentially a loop of being told things, followed by exploring and then asking more questions until the person is comfortable and familiar with that part of the system. This process should not be rushed.
Knowledge silos are an inevitable fact of life in many environments. We could talk all day about the things that cause them, but the real trick is knowing how to get rid of them when they happen. While advantageous for a while, knowledge silos can eventually become expensive, risky for the company, and can make innovation difficult. If you want a long career in tech, one of the most important things you can learn is how to cross train yourself and others. Doing so eliminates knowledge silos, making the team more productive, more resilient, and more able to quickly innovate when changes occur in the world.
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.
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.
Tricks of the Trade
Be careful that you don’t paint yourself into a corner with your own training and knowledge base. You want to have enough breadth of knowledge to be able to pick up on the new stuff but not so wide that you never get good at anything. On the reverse you want to have enough depth in an area or two to be the expert but not so much that you neglect learning other areas that may benefit what you are doing in your area of expertise.