# Avoiding Knowledge Silos
One common issue in teams is creating knowledge silos, meaning that you have a single person that knows almost everything and in the worst case, only that person is able to solve an issue. While it certainly helps that you have an expert on board, that knowledge must be distributed in the team so anyone is able to solve upcoming issues or challenges. What if that single expert is on vacation, leaves the company or gets hit by a bus? We always referred to the "bus-factor".
The bus factor is a measurement of the risk resulting from information and capabilities not being shared among team members, derived from the phrase "in case they get hit by a bus."
I remember, in my previous company, when a developer left, everyone panicked, due to the bus factor. Each developer usually had an immense amount of knowledge silos and they had to do hand-overs for the last few weeks of employment.
If you work in a team with multiple people, the risk of creating knowledge silos can be mitigated to a minimum.
Involve developers early on
The product managers integrated at least one developer early on when working discovering new topics or planning them. When a new topic came up and the product managers needed support from a developer, one developer volunteered to be part of conception. Each team member kept an eye on rotation so not the same developer gets into conception every time. This allowed the other developer focus on their tasks without interruption, led to better stories, acceptance criterions, less discussion in planning and reduced knowledge silos. For huge new topics, two developers were involved in conception with the product managers.
Rotate as much as possible
Don't cherry-pick tasks. As we worked with Scrumban, when we finished a task, we first checked if anyone needs support, if not, the next top priority ticket was grabbed. No cherry-picking. This also led to a natural rotation in tasks.
Sometimes it doesn't make sense to forcefully rotate, i.e. on a technical follow-up story that can easily be solved by the one who initially implemented it. We did apply common sense as when not to rotate.
Rotation is key. For most meetings, we only sent a single representative of the developer team. That representative switched every time so the knowledge gets distributed.
The Daily Logger that kept an eye on bug reports, logs and monitoring switched daily and we rotated through the entire team.
Document
Every developer commented progress in Jira and wrote a summary in Slack on story completion. We also had a weekly developer meeting to discuss any interesting technical changes/additions. Before leaving for vacation, we had to check for any open topics that may needed to be handed over. In case of illness or vacation, that transparency helped continue tasks and we didn't have to wait for the developer to return.
I'll be honest, this didn't work out every time. People forget. Your mind is already on vacation and you forget to hand over the open topics. You forget to document your progress and fall sick. The key is for the entire team to pay attention to this and keep reminding everyone to do it. We all had common ground on what made sense. Sometimes, all it needed was a little reminder or little slap, metaphorically speaking.
Pair Programming
Pair programming also helps sharing knowledge among multiple colleagues. We did not enforce pair programming and let the developers decide when to pair.
Summary
By being transparent about what you do, sharing insights with the team, rotating as much as possible, you can greatly mitigate the bus factor. While it may initially slow you down, this is going to save your ass in the long run. When your colleague falls sick or leaves the company, you no longer need to panic. Create an environment that promotes transparency and knowledge sharing.