Hi, I am Peter, a server side engineer from Unifa.
Recently, I had dinner with a few old friends I hadn't seen in a while. We're all software developers, so naturally, over the course of the meal, we found ourselves discussing some of the everyday situations that development teams face. One thing we touched on is the symptom of knowledge silos in software development teams.
What is a knowledge silo?
Do you have the experience that every time you have an issue with your app, and you ask for help, everyone always just points you to that “one” engineer (let’s refer to him as “Mr. Mastermind” in this article)?
Imagine if “Mr. Mastermind” went on holiday. What would happen if there is a production issue or an urgent attack on your platform? Everyone would probably panic because no one would know how to save the fire!
Why does knowledge silo happen?
This often is caused by a prioritization of efficiency versus availability in project management and delivery.
In software engineering, it takes a long time to get familiarized with the code base. As an engineer that has worked in a variety of projects in the past, often to onboard a new codebase, it can take multiple days just to understand how things works, and for a less well maintained codebase, it may even take weeks just to understand and deliver valuable work in a codebase. Therefore, if “Mr. Mastermind” can solve your issue quickly, it can be rather costly to deploy another engineer to this codebase.
This will end up causing the team to be in this situation, where either “Mr. Mastermind” can never go on holiday, often on call, and work extra hours on critical issues. Imagine if in the engineering team, everyone functions as a knowledge silo, does that look like a great team to work in? Certainly not in my opinion.
So what might be a different approach we can take?
Prioritize availability to efficiency
There are a few things that I can think of that help improve this situation:
Put more buffers to delivery date to allow flexible arrangement.
Focus on delivering fewer projects at the same time, so engineers can work together and learn from one another.
Opportunistically put engineers not so familiar with the code base to the project, or pair engineers with experienced hands.
Pair programming.
I've noticed that many excellent teams possess at least some points from above.
The benefits to doing the above are:
The engineering team eventually will have more skills than before, and since engineers are growing, they have passion to keep working there.
It builds a working environment for knowledge sharing, a more maintainable code base, and a higher team spirit.
It allows team members to have a holiday without worrying about the software in risk of production issues.
Eventually, due to an upskilled team, the team actually delivers faster, and scales up faster as well!
So this certainly sounds like a win-win situation for the business and the engineering team!
How does that relate to a software engineer?
You might say that this seems to be something the engineering manager should think about, so why should a software engineer care about this?
Interestingly, to be able to play out described above, it requires engineers to be passionate about making that happen. I will give a few examples where engineers can play a role in this:
In a planning meeting, you can volunteer to take projects that you are not experienced with, and ask familiar hands to help you.
You can write documents to share your knowledge about your system, and volunteer to make knowledge sharing sessions to the wider team.
When you write code, have the mindset that if someone else will jump into this codebase soon, they can have less friction. For example, good README to explain how to set the app up, strong unit test coverage and integration test coverage, highly readable code that is self explanatory are all highly helpful.
Give a time estimate for delivery that covers the need to do knowledge transfer, documentation and more maintainable code, not just to ship a feature.
I am sure creatively as you are, there are a lot more things you can come up with!
A real world example
In Unifa, we have many projects that aim to build new features (and these systems are mostly integrated with each other), while we still have maintenance work behind the scenes. Moreover, we have new engineers join the team as well. In this environment, ensuring that each project moves forward smoothly is indeed not an easy task.
Therefore, as you can imagine, there is certainly no best solution, only the one that is most suitable for your own team for the specific situation you are in.
One of my friend shared how their team work, which seem to work pretty well, and it also has some similarities with the current development team at Unifa:
Every project was allocated 2 engineers, with one primary and one secondary. The primary engineer plans and documents the project and involves the secondary engineer with most of the discussions and code reviews, so both engineers have a good context of the project. The code delivery was done mainly by the primary engineer, and occasionally, pair programming is used when a certain part of the work requires more multi-discipline knowledge.
Working this way, the code review is often fast and effective, and when someone is away, the other person can handle the majority of the conversations, which effectively helps the team navigate through the situation, and eventually every engineer becomes very capable with all the code base the team owns.
Conclusion
Because teams may want to try to ship as fast as possible, this often leads to knowledge silos, which eventually slow down the team, and bring down team morale.
Taking an alternative approach to prioritize availability to efficiency will benefit the team in the long term, where we can eventually see more team members being able to support any project effectively, code bases improve maintainability, achieve a sensible delivery speed and create an engineering team that enjoys working hard in this environment!
