One of the leading challenges that engineering leaders face is spotting knowledge silos. Left unidentified and unaddressed, these silos snowball into dependencies on individual folks who may (unintentionally and, possibly unconsciously) start holding teams back. At one point in my career, I remember being tasked with changing a small detail around how our iOS app was configured in the Apple Store. Normally, our great founding iOS engineer would be the one doing the task, except this time he was on parental leave, so the task fell to me.
When I started, I quickly realized I wouldn’t be able to get it done — not in an hour, a day, or a week. Why? Because the engineer responsible hadn’t uploaded the credentials to the password management system before leaving. After all, why bother when he was the expert who did everything iOS related, quickly and well. In this case though, the work was urgent as we realized we had been doing something illegal (since we only started having a legal team recently), so it needed to be done, fast — but we couldn’t.
See what happened there? A knowledge silo got the best of us! So the question now is: how can you avoid such a knowledge silo and subsequent one-person-dependency in the first place? I’ve a few ideas for you.
But first, why do knowledge silos crop up in the first place?#
It’s normal that early-on in a company’s life, there are things that only one person knows how to do or only one person has the correct permissions to do. Ideally, these scenarios are contained and are not mission-critical. For example, it’s okay to have only one CSS expert who is able to get the animations "just right" really quickly. However, it’s not okay to have only one person with knowledge on how to rollback a deployment.
Similarly, there are instances on teams where there’s no discussion or process around who will work on a certain task. Rather, roles are implicit — going by internal names like ‘the DevOps specialist’ or ‘the backend girl’. There are also cases when engineering managers or product partners, who, when they need something done urgently, go straight to a specific engineer. In doing so, they often bypass team processes and ceremonies.
There’s one thing that instances like these tend to indicate: if left unattended, they run the risk of opening potential knowledge silos.
How can you identify knowledge silos?#
The key here is to look for, or rather listen for one-person dependencies. To do so, keep an ear out for phrases like these that indicate you have single-person dependencies:
👉 “I didn’t want to work on that task because really senior engineer X is on holiday”
👉 “I need to ask founding engineer Y to deploy because they’re the one with permissions”
👉 “I’m waiting to merge after a review from DevOps expert Z as they’re the infrastructure as code expert”
Put simply, any time something doesn’t go as expected because an individual person was unavailable suggests you might have a problem.
3 solid ways to avoid knowledge silos#
Now that you know that knowledge silos can easily birth single-person dependencies and slowly but surely become a pain, here are 3 ideas to help you avoid them in the first place:
1. Design teams with knowledge silos in mind#
Avoid having teams with only functional specialists. Have at least some full stack engineers or multiple people who can work on any type of task the team is likely to do. This will help you create a culture where all team members are comfortable trying any type of task.
To go about doing so, always ask the following question explicitly during low-level team design: will more than one person be able to handle each type of work that this team does?
2. Organize team rotations#
Another best practice is to organize team rotations or team ‘safaris,’ where members permanently (or temporarily) join other teams within the organization. This helps encourage knowledge-sharing across teams, giving people the chance to learn from others they haven’t previously worked with.
On the plus side, team rotations not only help employees learn new stuff but also encourage individuals to develop empathy around how others work — creating a sense of respect for each others’ work throughout the organization. Since only a member or two from a specific team works with another team during these safaris, each team can continue to function normally.
3. Make sure all essential tasks are completed by two people#
Lastly, make sure at least 2 people can do all essential tasks required to get software into production. Even if only 1 of the 2 can do the work well, having two people know the ins and outs of the task saves you from having knowledge limited to only one person.
Side by side, make sure the “how-to” behind these critical tasks is supported by documentation that everyone has access to. Again, this way everyone has access to knowledge — helping you reduce dependency on a single person.
Knowledge sharing practices#
Good teams share knowledge as a practice. This can be done in a number of ways:
Invest in documentation#
Create guidelines around how to document the right way including where to host all the documents and what formats to package information in (for example, short screen-recorded explainer videos or checklists). Remember though, documentation takes time. Plus, documents can quickly become stale, repetitive or confusing.
Setting guidelines for documentation and penciling in time for creating knowledge-sharing documents will help. It’s also important to dedicate time to updating those documents regularly otherwise all the work done can quickly go to waste.
Organize knowledge cafe sessions#
These are ‘show and tell’ sessions where teammates share how they get X done. Include time for Q&As in these knowledge sharing sessions and you can create a productive peer-learning environment in your organization.
The only con to these sessions is that sometimes they can be daunting for introverts and not as value-packed for people who like to learn by getting their hands dirty. Conquer this by asking people who are willing to give show and tell presentations. As for the introverts on the team, ask them if public speaking is a muscle they want to build so you can motivate them to host such a session.
Work in groups#
This one’s my favorite way to share knowledge— work in groups (mob programming, or in pairs). In such knowledge-sharing sessions, all employees get the chance to learn by getting their hands dirty. This makes it one of the most value-packed ways of creating a culture of learning and preventing knowledge hoarding.
A common complaint about it though? It slows the team down. In some cases, yes, it probably does, but only in the short term. If the Java Rockstar has to pair with the frontend newbie, for example, that backend ticket deep-diving into JVM garbage-collection is probably going to be completed more slowly.
However, this only creates a lower maximum velocity on a specific task for a short time, because the following week you’ll have the same front end newbie chipping in on backend-only tasks —saving you from having to invent low-value work specifically for them. Similarly, the Java Rockstar may leave to go work at another company, and until you hire a new rockstar, you’ll have the front end newbie to keep pushing the product forward.
In short, bearing a small slow down will pay off by helping you save lots of time in the future — making it all worth it.
Parting thoughts#
Nobody works every day of the year and very few people will want to stay at your company forever. This makes it important to prevent knowledge silos and save your organization from single-person dependencies. You’ll want to invest in documentation, host knowledge sharing sessions, and organize team rotations. Most of all, design teams with knowledge sharing in mind.
If you still find yourself deprioritizing knowledge sharing, I’ll suggest you assume that on the day of your biggest production emergency or most critical customer emergency feature request, your MVP engineer will be happily celebrating the birth of a child or getting married.
With assumptions like that, you’ll be on the road to preventing knowledge silos.