How to melt The Bus Factor on your teams
The Bus Factor is a prelude to the disaster. The fact that only one person has all the knowledge puts at risk your whole team and, potentially, your organization
The Bus Factor represents the risk of having all the knowledge, that is critical for your business (either a company or a dev team), in one single person or a small set of people.
Let me give you an example of Bus Factor. It happened to me once, that I had to take over a set of services that were managed by one single person. This person was even in charge of manually deploying in production those services, even without acknowledgment from the IT Security team. When I say deploy, I say doing SSH into the virtual machine, do SCP the new JAR file into the virtual machine, stopping the service, replace the JAR, and restart the service.
This is bad in many dimensions, but in today’s issue, we will focus on the fact that all that process, was known by one single person. What happens if that person is run over by a bus?
In today’s issue, I will address how to detect a bus factor in your team or organization, and I will give a set of actionable items to thin that situation.
Finding The Bus Factor
Sometimes, it could be difficult, for an Engineer Manager or Tech Lead, to identify a bus effect on your team.
For this, I’ll explain some scenarios and behaviors that you can try to find in your team and, later, I’ll provide some action items to make those scenarios appear, if they are there, under your team’s carpet.
Here are some scenarios you try to find:
The majority of the team members always ask the same person for help or pieces of information about their area of influence.
It is always the same person that has to jump into support tickets to make them solved.
It is always the same person that has to jump into production incidents.
It is always the same person that can make the onboarding or transfer knowledge sessions to the newcomers.
That very same person is your bus factor.
It’s important to not get confused between the bus factor and the fact that you could have an experienced person in your team that can adapt and overcome different situations.
Now, let me share with you a couple of actionable items that you could use to find the scenarios mentioned previously
Interview your team members. Ask each of them, in an open and trustable conversation, what they would do if they have to face the scenarios I mentioned above.
Observe your team. It’s equally simple and effective. You will see this person acting as a bus factor very often. Usually, the bus factor is a person that wants to help and get things done, reproducing the scenarios mentioned above all the time.
Now we know how to identify the bus factor, let’s see how can we make it go or, at least, mitigate it.
How to melt The Bus Factor
Now, I share with you the main strategies that worked for me for diluting and, at some point, making the bus factor disappear.
Work over use cases. Doing a code 101 session, even though I believe it’s important to do so, it could be taught to the engineers and most likely will not bring all the value they need. However, if you define a set of use cases that the engineers should be able to satisfy, your transfer knowledge exercise is more focused and concrete.
Some examples of potential use cases could be:
How create a new endpoint in the service?
How to add a new validation step to the request call workflow?
With this in mind, the engineers will have something on which to get focus during the transfer knowledge sessions.
Schedule transfer knowledge in a continuous manner. One single transfer knowledge session is not enough. Let’s not be naive, in software engineering, it’s not even enough if you are able to arrange 3 sessions. My recommendation here is that you organize small and focused transfer knowledge sessions from time to time. In between of those sessions, the team members will have the opportunity to think about questions for the next session.
Put some team members to work on the legacy code. In rotation mode, you should make that all your team members work on the things that the bus factor person knows and the rest do not know.
Make the transfer of knowledge a priority. If you are Engineer Manager, you are in a position to set goals for your team members. If you are not, and you see this need, talk to your manager and provide this feedback.
Final words
The bus factor sometimes is something you do not see until it hits you and, when it hits you, usually it’s bad. If you are coming into a new team as Tech Lead or Engineer Manager, I would recommend you start identifying if it’s the case of your new team and jump into it. Also, when there is a re-organization of teams, and new members arrive at an already existing team, this bus factor could appear as well.