Knowledge Silos

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. Episode Breakdown 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 reco...