If you followed our Digital Poirots, you have most definitely heard of data silos. An occurrence where all data is centralized in one place without allowing others access to it. Almost the same characteristics apply to knowledge silos. The principles are the same and you might imagine where this is going. But, we’ll get onto that in a second.

Software development has never been a one-man-team project. After all, the quote “No man is an island.” has never rung more true than in software development, especially in big projects. The core of every software development company’s culture is collaboration and teamwork. IT companies thrive on that and center the whole environment on it. So, when knowledge silos appear, it becomes harder and harder to foster such a culture. And breaking knowledge silos becomes a priority.

What exactly are knowledge silos?

Knowledge silos happen when an individual or a group of people know something, have some information or skills, and don’t share it with others inside the organization. They happen when individuals or teams don’t want to exchange information, communicate, or collaborate, whether we’re talking about with other teams or departments. 

In software development, knowledge silos appear when one person or a group hold skills, expertise, or historical knowledge on projects or programming and doesn’t share it with other team members. Why is that such an issue? Because of a term called the “bus factor”. 

The bus factor is a measure of risk when someone holds skills, information, or knowledge only privy to them. So when this person goes on vacation or leaves the company, others can’t pick up their work. The term is derived from the statement “What if they get hit by a bus?”. The question is who will in that scenario be able to continue this person’s work? A bit ominous and selfish statement, but it’s unfortunately necessary for work organization and dispersing knowledge silos. 

Why are knowledge silos a no-no?

Well, sharing is caring. The same applies to knowledge. It’s not about forcing someone to share all their hard-earned expertise, but it’s about company and project information. Sharing technical skills and mentoring others is a perk in creating cohesive teams that are oriented towards learning. 

Knowledge silos are especially bad when you have teams with different skill sets. Meaning, that not exchanging information between, for example, product development, project managers, developers, and similar, could lead to a bad product, or software in this case, delays, and issues. Poor communication leads to way too many bumps in the road. 

Here teams work almost in isolation and don’t know what others are doing. This ultimately causes work duplications, miscommunication, incompatibility in goals, slower time to finish projects, intolerance towards unintentional mistakes or others, and discrepancies in work progress.

Knowledge silos basically alienate teams and remove all cohesiveness. Yes, you can argue that one team leads one project and everyone doesn’t need to be informed. That’s true, but still, unexpected issues might arise and others will need to be onboarded onto the project. This then takes time and creates additional costs. And you want to avoid that completely. You can compare silos to high school cliques. Each group does its own thing and it’s hard to become a part of one. And, unfortunately, they will work against each other.

Break it or don’t make it

The best thing for you and your company is to try and break knowledge silos. Your software engineering teams are dependent on collaboration, especially if we talk about big and complex projects. You don’t know whether the scope will change in the future or new complex requirements will come in. In this case, you’ll need to bring more people onto the project team and it could be rather difficult for them to catch on. More issues arise if they need to catch up on new technologies or other changes. 

Create documentation on projects and identify critical knowledge

Creating documentation should be a standardized procedure, meaning that each team member should consciously and continuously write it parallelly with their work. It is especially beneficial if one person leaves the project and another has to be onboarded. This is also great for avoiding creating complex legacy code with poor documentation. 

Identifying critical knowledge each team member has to possess is also vital. Certain things can be standardized if they are a part of everyday operations and procedures. 

Pair programming

Pair programming is where two developers work on the same computer to design, code, test, and review. This is great for knowledge sharing and collaboration since developers provide each other with insights and new thinking. With pair programming, there is a way to ensure that more than one developer knows everything about the code and project.

Share activities and communicate

What’s important in most companies is to regularly do hands-on meetings to share information on current projects and activities. It’s not always about knowledge sharing, but about informing other team members on cultural and organizational activities. In such situations, someone might share issues and problems they encounter in their tasks, and others can help solve them.

Create initiatives and time for knowledge sharing

What software development companies can do is offer tech sessions where the more experienced or more knowledgeable developers can share their knowledge on certain technologies or best practices. This fosters a culture of improvement, and also, developers feel more validated as valuable team members or mentors.

Involve developers in each stage of development

We know that most developers would love nothing more than just to code. But, to avoid knowledge silos, it’s beneficial to involve them in the development process from start to finish, from learning about domain knowledge to product delivery. This way they will understand better what they are working on and can provide input when needed. By knowing what others are doing, they can learn more and perhaps provide some guidance or advice.

Code reviews

Code reviews are software quality assurance activities where more people asses the code, get themselves familiar with and learn the source code, find bugs, and increase code quality. By doing code reviews other developers who haven’t worked on the code itself, get to know how was it written and done in case they might have to revisit the code later on. 

Draft pull requests

Draft pull requests are a great way to start conversations and collaboration on the code that isn’t ready to merge yet. They are a way to get feedback from your colleagues and for them to suggest improvements or indicate some faults in your code. This collaborative activity invites developers to work together to create the best possible solution and for them to be acquainted with other peoples’ work.

Rotate developers in meetings or PM/BA activities

Sometimes developers get to sit on meetings with PMs and BAs while they work with clients. This is the best way for them to know what they’ll be working on and what is expected of them. It’s also a good way to acquire domain knowledge and provide advice on which features are feasible and which are not. So, it’s also a good idea to rotate developers in those meetings, so each one gets the chance to dive deeper into the topic and project at hand. 

Avoid cherry-picking tasks

Tasks should be assigned by priority and not by favoritism. Developers should be given tasks as they are, in order they are prepared for sprints, successful project interactions, and delivery. Don’t allow developers to choose the task for themselves and to choose those they feel most comfortable with. If a developer stays just within his domain or specific part of the project, they are creating knowledge silos and preventing others to join.

Build trust and tackle issues head-on (prepare for problems)

Trust is extremely important in any company or organization. If your team doesn’t trust each other, they will never share their work, knowledge, or information with their coworkers. Without a culture of trust, groups of people will form and certain referent groups won’t allow others in. Also, have set strategies on how to tackle issues and resolve them as quickly as possible. You have to prepare for future problems and educate your employees on how to approach them as well.

Create cross-functional work

This has been around for some time, and it’s no news. Development companies have been creating teams with various backgrounds and positions or qualifications. Now, in one team you have developers, QAs, PMs, BAs, and business, all working toward the same goal. This allows them to share knowledge. They probably won’t all know how to do each other’s work, but they’ll get a better sense of how everything works and what are some best practices. Interlacing different professions leads to growth and outlook broadening. 

Kill a silo and prosper

Breaking or killing knowledge silos is not easy and it can’t be done instantly. It takes time and true effort to do so. The process of eliminating knowledge silos is a long-term strategy that should be implemented from the start in the company culture. The methods and activities described above should be practiced continuously and not only when silos occur. The goal is to prevent them from forming before it’s too late. 

Organizations should anticipate knowledge silos and preemptively work towards stopping them from forming. If you foster a culture of collaboration and growth, your team members will work on sharing their knowledge. They will strive to learn and share information since they know that the whole team works towards the same goal.