Why We Avoid Knowledge Silos
We avoid knowledge silos.
Remember when you were little and someone told you a secret? Whether it was someone they liked or a funny story they heard, you felt excited that they trusted you and that you knew the secret. Fast forward to the present day. Carli is a software engineer who has worked at the company since the very beginning. She has a secret, the knowledge of how the reporting module works. This module is key to the company’s success and she’s the only one that ever works on it. Carli frequently rejects offers by other engineers to help out with the code or to learn about how it works. Because of this isolation, Carli never gets any feedback on the code and the codebase remains stagnant.
As time passes, Carli decides that it’s time for her to move on and takes a job with a different company. Her current team members and leader scramble to learn as much about the reporting module as possible before her departure. During Carli’s last week, she hands the code over to another engineer, Sean. The handoff is rushed and Sean has tons of questions, to which Carli typically responds with “I don’t really remember” or “I’m not sure why I did it that way.” It doesn’t help that the code is in a language that only Carli knows. At the end of the week, Carli leaves and Sean is now the new owner of the reporting module with only a few hours of handoff.
It quickly becomes apparent that what little knowledge Sean has gained is insufficient and that the codebase is in rough shape. The team now has a few options, none of which are particularly stellar. Sean could continue working in the current codebase, in a language he doesn’t fully understand, trying to make as few and as small changes as possible. Alternatively, the team could choose to fully rewrite the reporting module in a language they’re familiar with and take a more collaborative approach. Both options have significant drawbacks and financial implications. Unfortunately, there is no right answer, either option is ultimately detrimental to the team and the organization. With that in mind, let’s instead focus on how to prevent this lose-lose decision from arising in the first place.
Avoiding knowledge silos is a significant risk reduction strategy. By ensuring that no single team member exclusively knows everything about a particular feature or workflow, we can build more stable products. Had the team pushed Carli harder to collaborate on the reporting module, they would have more historical knowledge. Similarly, the code might be structured better since it would have been written more collaboratively. This type of knowledge sharing often occurs through pair or mob programming. Alternatively, a thorough and well thought out pull request process can also help share knowledge. In a perfect world, knowledge of a critical function wouldn’t be limited to a single team but other teams would have knowledge of the functionality as well. This is harder to achieve and sometimes occurs organically as engineers switch between teams. Regardless of if it’s across teams or within a single team, frequent information sharing is a core tenant of successful product teams at Pluralsight.
Carli’s secret poses significant risks to the company. I want to be clear that this isn’t exclusively her fault, there’s plenty of steps her teammates and leader could have taken as well. Regardless, siloing knowledge particularly around critical components can create serious problems. As illustrated by her leaving, a single point of failure, even when it’s a person, makes recovering and moving forward difficult for her team. Sean was fortunate to get a brief overview from Carli, but she could have just as easily left immediately without any handoff. Part of Carli’s frustration was that she felt that she could never take a vacation or sick time since no one else knew how the reporting module worked. This contributed to her burnout and was a factor in her job search. And finally, imagine if another team was unaware that Sean had taken over the reporting module and they decided to rewrite it themselves as well. The amount of duplicative work that would take place would be substantial.
Knowledge silos are almost always detrimental to teams and organizations. And yet, they’re very easy to fall into. What might start out as something as harmless as “it’s just faster if I do it myself” or even a highly differentiated set of engineers can quickly spiral. Reducing knowledge silos early and often reduces risk to the team and can improve morale.
Checkout our Engineering at Pluralsight document to see all of the statements that shape our engineering culture.