I spoke before on this blog about BUS FACTORS and how to get rid of them. A bus factor is calculated the the amount of people on your team or project who need to get hit by a bus before the project comes to a halt. There is something that only THEY know how to do.
I am revisiting this because there are many ways to get rid of it. Today I cover a couple. But first, a true story.
The Robot
In one of the projects I was consulting for a few years back, we had four teams and many bus factors relating to many things. One of them was related to the search technology the project was using at the time (sharepoint search…shudder!)
One day I saw the architect* running around like a headless chicken trying to figure out how to fix a problem. I asked him what’s wrong and he said “the search guy is out on vacation this week and not answering his phone. I have no idea how to fix this”.
It took a couple of hours until he found an external company that once provided these services to the project, and got them on the phone to ask if they knew how to fix this problem. Of course they did. They coached him on the phone what to type to reset some indexes.
I was sitting in the next seat listening to him typing word by word into the terminal, pressing enter, and then saying “ok now it works thanks”.
Then he hung up.
What a great loss of knowledge! Instead of using the opportunity to LEARN something about the problem, its causes and WHY what he typed fixed it, he simply made himself a remote controlled robot for the person on the other side of the phone.
I coached him to do the following next time:
When you find the situation has been solved, ask the following questions on the phone:
-
- What exactly was the problem? (tag this type of problem in your mind. like a design patterns, we can have “problem patterns”)
- What made you realize that was the problem? if you indeed realized it. (learn their thought process. learn to think like them)
- What did the actions we just took mean? where can I learn the full syntax of those commands? (learn the solution pattern)
- Who else around me knows what you just told me? (see how bad the bus factor really is. Maybe you just did not know who to ask? maybe you are the ONLY one who does not know how to do this?)
Pull Based Learning
What I coached him to do was what I call “PULL Based Learning”. Before I discuss that, let’s talk about why it is important to learn this pattern.
One of the best ways to remove bus factors, is by pairing. Pairing is an act of active learning where knowledge is constantly back and forth. A person asks a question “How did you do that?” . that is an act of deliberate learning.
But pairing is also hard to achieve in a culture where pairing was never a “thing” people do. If you cannot get enough people to pair, or the bus factor is happening when a person from a DIFFERENT team knows something that your team replies on, it’s time to start encouraging active knowledge gathering, or active learning.
Active learning comes in two forms, or two directions:
- Pull Based Learning: The person who does not know X asks another person who knows X to teach them about X in some way. They initiate a PULL of the information from the other person.
- Push Based Learning: The person who knows about X asks a person who does not know about X to join them to learn about X. They initiate a PUSH of information towards the other person.
So pulling or pushing depends on who initiated the knowledge transfer. If you find that you have many bus factors, it is important that you teach and coach people how to work in BOTH directions:
- When people who need to learn are too shy to ask for help, coach the more experienced people how to PUSH knowledge by asking others to join them in a task that will teach that person something new.
- When the people who are the bus factors do not have many opportunities to share knowledge** coach the people with less experience to jump in when they see the bus factor doing something the less experienced person does not know how to do that affects them, and ask to join in for a few minutes to see how things are done.
Get Permission
This also means you might need to get an upper level manager to send an email or have a group meeting letting all developers know that “it is OK to do pairing, ask for help, request someone to join you to learn new things – even if it means tasks take longer than estimated. it is OK to estimate tasks longer because you want to build these things into your iterations”.
In cultures where hierarchy matters a lot, this could be the beginning of the breakthrough you might be looking for – giving people permission to learn and teach is usually the thing most cited (by people I ask) as the reason why they are not doing it.
Bi-Directional Knowledge Handshake
Having only a single direction knowledge sharing culture is very ineffective.
In a project full of consultants, who love teaching, but also full of people who hate learning, knowledge will not be shared very often, and if so, with a tea spoon instead of a fire hose (which is usually what you need to start with in extreme cases)
In a project full of people wanting to learn, but having all the people with the knowledge be in a different building, company or country, mostly unavailable, knowledge will not be shared.
There has to be a knowledge HANDSHAKE for knowledge to actually flow through. otherwise we are talking about tear drops in the ocean.
Notes:
* Remember that having a non coaching architect is having a bottleneck
** Maybe you should think about increasing the amount of opportunities?