With any long-running software project, the need to educate others on a block of code, architectural design, or business process will likely occur. These knowledge transfers (or KTs as the cool kids call them) are often needed when a developer or subject matter expert leaves the project (sometimes unexpectedly) or when a project wraps up and is handed off to the client.
The goal is simple - make Person A understand something to the same degree that Person B does. And this sounds appropriate, right? Why wouldn’t you educate the team or client on the inner-workings of a project? There’s nothing wrong with the idea; the problem is, knowledge transfers just don’t work (usually).
Most developers are familiar with the experience of sitting through hours of KT sessions, slurping up every detail thrown at them, only to feel totally lost when first working in the area that was described. Why is this happening?
Why Knowledge Transfers Fail
There are a lot of small, easy to understand reasons why KTs fall flat on their face. Poor communication or teaching skills, a rushed timeline, or an extremely complex or convoluted subject area are just a few examples. In my experience, however, there are two main reasons why knowledge transfers fall flat on their face.
The knowledge giver is on their way out
As previously mentioned, the need for a KT often occurs when someone is leaving a project. Sometimes the need for a KT comes up suddenly, such as when a developer quits or is fired. When this occurs, the knowledge giver is often not in a position to adequately transfer their wisdom to another. For example, they may be too busy wrapping up loose ends to develop a meaningful KT plan (How can I train the new guy when I have these 10 defects to fix before I go?), or they may simply be checked out and not too interested in educating their replacement (How that code works is the new guy’s problem, right?)
In any case, without the outgoing individual’s full participation, the knowledge transfer will suffer.
The knowledge transfer is only an information dump
To be truly effective, a KT must be accompanied by some sort of immersion in the subject area. Real understanding won’t come from being walked through blocks of code or being shown diagrams and flowcharts. Real understanding, real knowledge, comes from actions that help the brain to solidify the new information it was just given.
Strangely, knowledge transfers are almost always the first thing a new developer takes part in when joining a project. Does anyone really expect that the new guy will remember the details of that complex decision engine when he’s given his first task on it five weeks after the KT? Of course not! It’s nonsense, yet it happens ALL OF THE TIME.
When Do Knowledge Transfers Work?
It’s not all doom and gloom with failed Vulcan mind-melds. Sometimes that matrix-upload actually works and you get your Kung Fu.
Knowledge transfers tend to go really well when the person receiving the information is already embedded in the team, is familiar with the project, and is simply learning a new subject area. In these situations the knowledge receiver is often tangentially comfortable with the subject area and is simply filling in gaps in their understanding.
KTs can go well with new team members too. A new developer whose knowledge transfer is accompanied by a meaningful application of that knowledge (i.e. writing some relevant code) is far more likely to understand and retain the information that was just passed on to them. This goes especially well when the knowledge giver is still around to guide the new developer and answer any questions they may have.
How to Get the Most Out of Your Next Knowledge Transfer?
Fear not - all hope is not lost. The following actions can be taken to stop your next KT from being a complete waste of time:
Accompany the KT with actual experience at the same time
As mentioned above, real understanding comes from immersion and by doing. Putting new knowledge to work immediately moves information in the brain from theoretical to applied.
Have developers follow coding best practices
Code that is written to be easily digestible - be it through small, single-purpose methods, appropriately named variables/methods, inline comments, etc - in effect create a second knowledge giver. Code that is easier to understand makes the problem it is solving easier to understand.
Consistently share knowledge through the team
Keeping everyone on the team cross-functional greatly reduces the need to ever have a KT amongst existing team members. An easy way to do this is through code reviews. A code review increases awareness of how a developer’s code works. In effect, every code review is a KT in itself.
Document architecture and processes
Don’t rely solely on the team members to be the source of knowledge. Your subject matter expert may be falsely accused of a crime and end up on the run, leaving you without anyone who knows how the Like button works. Putting information into documents allows you to maintain a library of always-available information, should anyone ever need to dust off the cobwebs of some rarely-touched feature. But be careful! Too much documentation can be a bad thing. An overwhelming number of documents, charts, and diagrams - can be just as much of a frustration as having no documents at all.
Recognize that no KT is 100% effective
Accept that the transition is going to be rocky. Some things will be forgotten and need to be figured out again later. It’s important remember that bumps in the road are expected and, hopefully, you’ve established some best-practices that will help cushion the ride.
No Worries. We’ve Got You.
Dream big. Rest easy. Contact Restless Labs to engage with software developers who understand best practices.
