Knowledge silos impede our ability to quickly deliver value to our users. We at Pluralsight are big fans of lean software development and one of the principles of lean is to create knowledge. Working to create knowledge will break down existing knowledge silos, prevent new ones from forming and improve our teams’ flow efficiency.

What is a knowledge silo?

Let’s start off by getting on the same page. In the strictest sense of the phrase, a knowledge silo is any knowledge that one person has that someone else doesn’t. That helps us out a bit, but there’s a huge amount of knowledge that any one person has that other people don’t. So let’s zoom in a bit to make this concept more useful. For the sake of this post, we’ll be talking about knowledge silos within a team. At Pluralsight, we work as product experience teams (PXTs). Those teams typically have a product manager (PM), some engineers, a DevOps engineer and often a product designer. They also may include data or machine learning engineers.

So one knowledge silo we see is between different disciplines. Generally, we’re ok with these types of knowledge silos. It’s fine if a PM doesn’t understand the specifics of how the developers implemented a specific feature. Or if a developer doesn’t know everything about some user research the PM did; a PXT has specialists for a reason. However, we should still be careful and look to share as much context as possible. How large those knowledge silos should be is dependent on many factors. The examples cited above are probably acceptable knowledge silos. However, our PXTs at Pluraslight have dedicated DevOps people. This is generally a more technical role, so how much of that knowledge should they share with developers, who are also in a technical role? Perhaps enough for them to do their most common tasks and to ensure they have a high level understanding of the infrastructure.

Another type of knowledge silo that has larger consequences is a knowledge silo between the engineers on the team. Some examples of these kinds of knowledge silos are not knowing how a piece of a system works or not understanding why code was written the way it is.

To finish up our definition of what a knowledge silo is, let’s talk about how different knowledge silos are harder to break down than others. On one end of the spectrum, we have knowledge silos that are impossible or extremely difficult to break down on your own. For example, let’s say one developer on your team has been off working alone on a complex portion of the code for six months. During this time they’ve had minimal code reviews and collaborated very little with others. Then one day, they leave the company without any warning. Or perhaps your PM and designer met with some customers and discussed some new requirements for a feature the team is implementing. To fully break down those knowledge silos, you need to talk to those people.

On the opposite end of the spectrum, we have knowledge silos that you can break down easily on your own. For example, looking in the code to see the structure of a given JSON object, looking up the current version of a library your code uses or seeing how many of your tests currently fail (hopefully none of them do!). You need minimal effort to figure these things out and can usually do it on your own.

Most knowledge silos fall somewhere in the middle of this spectrum. With enough time, you could probably figure out these knowledge silos on your own. However, having someone share context with you would accelerate the process. Examples include figuring out the infrastructure around deploying a service, understanding a complex part of the codebase or learning how a new unit testing framework works. The amount of time it takes to break down these knowledge silos varies from person to person. It depends on how much context they already have and their ability to learn and understand new concepts.

Why are they harmful?

Now that we’ve gotten some clarity on what knowledge silos are, let’s talk about why they’re harmful.

Creating Waste

Another core tenant of lean is to eliminate waste and knowledge silos cause a lot of waste. One way they create waste is secondary work. Secondary work is work we do that doesn’t directly deliver value. It’s meta-work. When one developer writes code on their own, for example, we need to do a code review or have a whiteboard session to explain the architecture of the new code. That code review in and of itself doesn’t deliver value, it’s just to break down a knowledge silo. Another example is when we have to meet with our designer to go over designs or ask them questions about specifics in those designs. It’s unlikely we’ll eliminate all secondary work and other waste, but breaking down knowledge silos or preventing them altogether will have an impact.

Building the Wrong Thing

Knowledge silos can cause us to build the wrong thing. For example, let’s say one developer on the team had a conversation with the PM about a requirement that changed. If that knowledge isn’t shared with the rest of the team, they may end up spending a lot of time building the wrong thing. So if we break down that knowledge silo sooner, we lower the chance that the team wastes time building the wrong thing.

Duplicate Work

Many codebases have an established pattern that solve common problems. Not knowing about these patterns can lead to duplicate efforts and waste. These established patterns can represent a knowledge silo if they aren’t shared or understood with all the developers on the team.

Slowing Down the Team and Bus Number

When only one developer on the team understands a particular part of the codebase, that leads to a few problems. First, whenever others work on that part of the code, it often takes them much longer to get work done. In extreme cases, the other team member may be the only one that can do that task. This takes time and is inefficient. A related problem is when someone’s bus number is 1. This means if they leave the company or go on vacation (or, heaven forbid, get hit by a bus), the other team members would need to overcome that knowledge silo on their own. In the case of a knowledge silo that’s easy to break down, this may not be a huge problem. However, the harder it is to break down, the more severely it will slow down the team. And in some cases, it may even block the team completely until that team member returns.

Impede Career Growth

One aspect of career growth is the ability to develop a deep understanding of a codebase. This enables a developer to contribute more effectively on their team. This process always takes time, but the quicker and more efficiently we can break down these inevitable knowledge silos, the quicker a developer is able to progress and grow.

What causes them?

In my experience, the root cause of most knowledge silos is a lack of collaboration. This can take a few different forms such as a lack of communication or one person working in isolation. Often you can recognize these knowledge silos forming; for example, if you find yourself frequently getting blocked because you need information from someone else, such as a PM, designer or another developer on your team. Also notice if you often have to refer people to another developer on your team to answer a question they have. It’s not the end of the world if these things happen, but just be aware if they become a constant pattern. There are more causes as well: someone new joining the team or someone having more experience with a particular methodology or technology. These knowledge silos are bound to happen and occur naturally, but we should still be aware of them and look for ways to break them down where possible. Regardless of the cause, there are several things we can do to break down knowledge silos.

How can I break down knowledge silos?

We’ve seen how harmful knowledge silos can be, so let’s talk about how to break them down.

Overcommunication

A root cause of knowledge silos is a lack of communication and information sharing, so the actions I propose below are all basically a variation on that. If it’s difficult to see the immediate cause of your knowledge silos, oversharing or overcommunicating can be a good place to start. Finding that balance is tricky, but err on the side of too much communication. You may want to share your intentions with others so they understand why you’re oversharing. It might be useful for your team agree on what to overcommunicate about based on the specific knowledge silos your team experiences. Then, solicit feedback and discuss how it’s going and dial it back as needed. A team retrospective is a great place to discuss these kinds of things. I recognize this approach has its shortcomings, but it’s better than letting knowledge silos continue to impact your team. One major shortcoming is that overcommunication is often an example of secondary work. However, by communicating earlier and more often during our process, we can avoid more waste later on.

Seeking Context and Asking Questions

One of Pluralsight’s values is “Seek context with intention” and proactively asking questions. Seeking context is a great way to understand where someone is coming from and gain a deeper meaning behind why they made a particular decision. Knowledge silos around intent are common, especially in product development. Proactively asking questions is one way to seek context and gain a better understanding. Both of these approaches require more effort on the part of the people seeking to break down the knowledge silo. But if you create a culture that values these behaviors, it will lead to teams sharing more and creating less knowledge silos.

Sharing Activities

Another strategy is to engage in deliberate sharing activities. Standups, retrospectives and other team meetings are great examples of this. Other times, you gain some new information and need to be proactive about sharing that information. For example, you may implement a new library or learn something in a meeting you attend. Sharing this new information may be as simple as a Slack message or bringing the team together to share and discuss the new information. This helps people stay informed and in sync, but you must strike a balance. Many people already hate meetings, so don’t waste time calling a meeting when a chat message or email will do. Again, erring on the side of oversharing, gathering feedback and then adjusting as needed can help you find that balance.

Code Knowledge Silos

Finally, when it comes to coding, pair and mob programming are two methods that we’re big fans of at Pluralsight. And one of their biggest benefits is how effective they are at decimating and preventing knowledge silos on a team. They allow us to both share context and add value to our users at the same time, resulting in much less secondary work and waste. And while we generally pair or mob with developers, having a designer or PM take part will further reduce waste and break down knowledge silos.

If pairing or mobbing aren’t your cup of tea, then having actual code reviews is another way to break down knowledge silos. And I’m not talking about a pull request (PR) where you quickly glance over the code and click “approve”. I mean an in-depth review where you discuss the code and understand at a deeper level. This may not always be practical, but doing cursory code reviews increases the likelihood of creating knowledge silos. It also creates a false sense of security because technically someone reviewed the code. But it may still lead to a knowledge silo because the review lacked depth. This doesn’t mean all PR reviews are useless, but in my career I’ve found I’m much less likely to dig deep to understand the code I’m reviewing in a PR. Anecdotally, I’ve had many developers tell me the same thing. Maybe this is more of a reflection on my own laziness, but the more friction there is, the more likely you are to create a knowledge silo. Again, it’s one reason pairing and mobbing are valuable and help minimize the secondary work of code reviews and other activities.

Conclusion

Knowledge silos can pop up everywhere in our work and can cause a big impact on a team’s ability to deliver value to our users. Notice when they’re starting to form, look for ways to break them down and prevent them from happening in the first place.