Last week, Johnathan Gonzalez of Worthington Enterprises posted a question on a myASQ discussion board, and it has gotten a lot of traffic. He asked, "When Quality depends on one person, do you really have a system?" Then he expanded the question with a little more detail.
Sometimes a process works because the process is strong. Sometimes it works because one person is really good at holding everything together.
Those two situations can look exactly the same until that person goes on vacation, changes roles, or leaves.
Most of us have probably worked with someone like that. They know the history behind a recurring issue. They know which supplier needs extra follow up. They know who to call when something goes sideways. They know which part of the process actually matters because they have seen what happens when it fails.
That experience is incredibly valuable.
The problem starts when that person's knowledge becomes the control. At that point, the organization may think it has a strong process when what it really has is a strong individual....
Where have you seen tribal knowledge become a real dependency in a process, and what actually helped transfer that knowledge to others?
Of course he is absolutely right that the two situations can look the same, and also that it is important to distinguish them. If your company depends critically on information that Tom and Larry carry in their heads, then—to put it gently—you are facing an important risk. And until you can get that knowledge spread across more people, you probably want to discourage Tom and Larry from taking up extreme sports or playing the lottery.
How do you spread their knowledge? Of course there are many ways. You can ask them to give talks over lunch. You can assign them to work on projects with junior colleagues, so that the junior colleagues rub shoulders with them and learn by doing. You can ask them to write procedure documents, though that kind of task is often postponed till the last minute because it's not very exciting.
Another approach is to create a wiki. The advantage of a wiki is that you can build it incrementally, a little bit at a time. But how do you remember all the different bits and bobs of topics that have to be included?
I once knew an engineering manager I've called Franz, who solved that exact problem. His organization had, at the tijme, some very senior engineers with decades of experience, and some new graduates who were just starting out. Naturally the new hires often asked the older engineers for advice, particularly around the design and architecture of the company's product line.
Franz introduced the following rule: "Whenever you ask a question, do it in email. And whenever someone asks you a question, don't just reply! Instead, add that question to the wiki. Write your answer in the wiki. Then reply to the original question by sending a link to your answer."
That was the protocol. It was simple. Everyone understood it. And over time it allowed the wiki to capture most of the tribal knowledge that the senior engineers had accumulated throughout their careers.
No single approach does everything. If you have to collect tribal knowledge, use multiple approaches at the same time, each supporting the others. But I have always liked Franz's protocol for filling up the local wiki with the knowledge everyone needed.