Team Knowledge Sharing
Many teams today have specific “go-to” people on a team. There is often a person who is the only one who has dealt with a specific feature or issue, and they are always the one that the team turns to when work needs to be done. What happens if that person is unavailable or busy with something else? Is the team sharing knowledge, or are they using the specialist’s capability as a crutch? Should someone be allowed to continue as the single point of failure?
Training and knowledge sharing go hand in hand. Team members can take a class or seminar and gain new knowledge about a technology. They might have institutional knowledge about something, which makes them the Subject Matter Expert (SME). Either way, forcing someone to be the single point of failure on a team isn’t a good idea. They should share their knowledge and experience with the rest of the team. Why is this so important? The apparent reason is to avoid delay when the SME is unavailable. No team should have a single point of failure.
The simple truth is that teams should train each other on their knowledge. Sharing knowledge is foundational for collaborative work, which software development inherently is. Software is rarely created by one person, and even then, someone will likely be asked to help as it increases in complexity. While documenting your work is always good (and I heartily recommend it), not everyone responds to mountains of documentation when a simple “show and tell” session can help them understand the key concepts.
I have heard many excuses for why someone cannot share their knowledge. Some say, “I am not a good teacher.” Others say, “I am shy and uncomfortable speaking on this.” The biggest excuse I hear is that the person doesn’t have the time. That last one is on the manager, in my opinion. If your people don’t have time to train each other, you must find a way to make the time for them. As for the other excuses (and yes, I chose the word “excuses” on purpose), there are ways to teach without being a professional teacher.
For instance, you can host a demo or a lunch and learn. Show off what work was done, briefly speak on any challenges they ran into, and then allow others a chance to ask questions. If you don’t know the answer, you can get back to them, but more often than not, the answers will come during the session. I have found that when people start talking about what they have done, especially when it was a recent endeavor, they will add more details as more questions come.
Demos are good anyway. They allow the team to show off what they have been doing and see their accomplishments. They also help to show a project's status to stakeholders and the wider organization, so taking time for demo work has plenty of value.
There is another classification of person who do not like sharing information because they want to protect their job. They won’t come out and say it, and often don’t even know they are doing it. As a manager, if you suspect this, it is essential to consider why they might be behaving in this manner. Do they feel that if they share this information, they are setting themselves up to be fired? Has this been their experience at a previous organization? Managers should try to identify this behavior and work with the employee to fix it. Ensure that they understand you are not looking to replace them. If someone shares information to better the rest of the team, they display leadership skills that can earn a potential promotion. If they are already a leader on the team but are not sharing information, new leadership should be considered. There is a vast difference between leading a team and bossing them around.
