Knowledge Transfer is not a thing, do this instead
According to Wikipedia, knowledge transfer “refers to sharing or disseminating of knowledge”.
As of late, as our engineering organization continues to grow, I hear this term “knowledge transfer” more and more often. Every week in some meeting a manager mentions a knowledge transfer session to make sure a developer gets up to speed on some task they need to complete.
Knowledge Transfer has become a cliché. Meetings are requested and scheduled for this mythical transfer of knowledge, treating it as a precious fruit of one’s labor to be handed to another.
And so calendar invites are sent, attendees gather in a video-conference and knowledge transfer commences. Right!? Sound familiar?
If you’re picturing a couple of awesome robots exchanging their bleeps and boops happily, completing the transfer and raveling in their new knowledge, you’re not alone.
To Err is Human, to transfer information is to Robot.
Except that knowledge is not a download. Most of us don’t sit down in front of a computer, browse to our favorite site, place our fingers gently on the nearest USB port and open up our minds to the wondrous transfer of knowledge from the great Internet.
Dare I say, even the most brilliant engineers I have the fortune to work with, do not learn in this way. Knowledge is not transactional, it cannot be transferred, only shared or learned. We are not living in the Matrix (that we know of) where information was literally downloaded to Neo’s brain, although the theory that our universe is a simulation has gathered some support as of late.
Yes, “knowledge transfer” is my pet peeve.
The danger of using these words is that they imply that it’s actually possible for some unit of knowledge to be transacted from one person to another, like a networking data packet sent, received, and acknowledged for receival. Except of course humans don’t work like the TCP protocol, and participating in a video conference does not equal learning, even when your attendance signals acknowledgement of information receipt. And so managers set unrealistic expectations that a knowledge transfer session translates to the attendees being able to execute the skill they got transferred to them.
And yet, knowledge sharing is a critical activity that must take place in every growing organization! Scheduling knowledge transfer sessions and even asking developers to read existing documentation and calling it “knowledge transfer” is doing a disservice to the very thing we hold dear — knowledge.
So I boldly claim again — knowledge can be shared and learned, not transacted.
Knowledge Transfer is not a thing, do this instead
Alright, we have accepted the error of our ways and we want to do “something” useful with this knowledge that one subject matter expert possesses and wishes to share with their peers.
Lets introduce a concept known well to educators — Learning Unit.
According to this publication, a Learning Unit is a formulation that facilitates change, a change that will result in the trainee being able to do something he or she could not do before going through the Learning Unit. In other words, Learning Unit facilitates ‘change in behavior’.
Ah ha! So as Yoda taught Skywalker how to use the Force, learning units are all about participating in an activity where you learn an information or a skill, and then demonstrate proof that you have understood the concept and can employ the skill learned successfully.
Many an online learning platform come to mind that do this fairly well. But how does the idea of learning units translate to a technology company regarding their internal knowledge?
One of the best tools for knowledge sharing that can be a stepping stone to a full learning unit is a technique called Pair Programming. In this activity, there’s typically a driver and an observer, or navigator. I will get into the full scope of benefits of pair programming in another article. For the purpose of learning units, pair programming encourages frequent switching of roles from driver to observer. This switching is the key — allowing the observer to learn, then demonstrate their knowledge under supervision, practicing this loop over and over. Although this technique is often used by programmers, it is really no different then an apprenticeship in any other trade.
But wait, there’s more!
As we shift our vocabulary and practices to knowledge sharing, we cannot ignore the scalability challenge. How do we enable many people to benefit from the subject matter expert (SME)? Below is one example how deep internal knowledge might be scaled across multiple practitioners.
- Identify a micro-skill that should be taught, shared, practiced.
- Create the documentation that teaches this micro-skill.
- Try out the documentation to make sure it works demonstrate the skill. Plan a workshop to teach this and define “successful outcome”.
- Schedule a 2 hour hands-on workshop, facilitated by the documentation creator/SME, where attendees learn by doing, and the SME helps them in a pair-programming style. Record the workshop.
- Adjust the documentation based on workshop output and publish the artifacts that include the workshop video recording.
- Content is now considered vetted, gets linked in your knowledge repository of choice and becomes an official micro-skill. Author gets a gold star.
Conclusion
Share your knowledge, teach by example, be an apprentice or find an apprentice.
And, please, stop scheduling knowledge transfer sessions. Your peers will thank you when you mentor instead, and your managers will hopefully observe real learning happening.
