Why Knowledge Transfer Matters And Your Developers Crave It
When I joined a large team at a Fortune 50 company as a contract iOS developer, I expected to be met with a well-oiled on-boarding experience. It didn’t take long to realize that my expectations and reality were as different as my vision gets when I open my eyes underwater without goggles. You see, I have 13 years of experience working in large US Government agencies, where the on-boarding process is quite extensive — perhaps overkill at times. Knowledge Transfer (KT) is also one of the top priorities at these agencies as often times positions have regulations that must be adhered to, or else you might see jail time.
Due to the loss of institutional knowledge, the team’s overall effectiveness is drained like blood from a victim with a severed carotid artery.
Why Onboarding Matters
A new hire, contract or salary — it really doesn’t matter, is the most vulnerable within their first few weeks at a new position. At this point, an organization has invested time and energy interviewing and selecting candidates, submitting paperwork for accounts, holding meetings to determine how to best use the new asset when they arrive, and so on; and the last thing the organization wishes to do is to lose those man-hours and the newly hired talent, but that is exactly what will happen if the on-boarding process is horrible or nonexistent!
The goal of on-boarding should be to make the new hire feel integrated into a team, give the new hire a vision for where the organization is headed, and set the expectation of how they will help move the team forward towards that goal. This Fortune 50 company did NOT do any of that. I spent the first two weeks trying to find as much information as possible, on my own, about the source code, what project I would be contributing to, and what the general expectations were so that I could be “the team player” I was hired to be! I began to look around, assess how the salaried employees seemed to interact with others, and I began to assemble an overall picture of the environment — to get a pulse on the outlook after I integrate completely into the team. Let’s just say, the outlook was a bit bleak. Lo and behold, I began to entertain new positions pretty quickly.
Knowledge Transfer Makes Contract Work Doable!
Organizations that have a significant portion of their development team composed of contractors often experience high turnover rates. This unique dynamic contributes to a “brain drain” effect within the organization. Due to the loss of institutional knowledge, the team’s overall effectiveness is drained like blood from a victim with a severed carotid artery. To stem the flow of blood, the panacea is KT! It may not be convenient, but it is vital in a high-turnover environment. Oh, and it just might reduce the turnover rate too.
Why Knowledge Transfer Is Vital To Business Success
KT is the means for you to lower the cognitive load for new hires to become more productive right out of the gate!
In addition to making a new hire feel integrated with the team, it is vital to get them up to speed on whatever it is they are being hired to do! If it’s going to take two weeks to get them provisioned to access the source code, let them know that up-front, but also give them a list of things they need to learn so they know how things are done at your organization! Believe me, each company does things differently. Some companies have the quintessential Software Development Lifecycle (SDLC), while others might skip a lot that they shouldn’t. Some teams organize their source code in a simple manner, while others have very complex architectural patterns that make the learning curve steep. KT is the means for you to lower the cognitive load for new hires to become more productive right out of the gate! Oh, and it also improves the team’s overall productivity as it homogenizes the team’s knowledge and skills so the weakest members learn from the strongest members and encourages the subject matter experts (SMEs) to share their expert knowledge, which can stabilize the intellectual and institutional knowledge leak (a.k.a. brain drain) from an organization when team members decide to move on to bigger and brighter opportunities.
IT Leaders Need To Be Bold
Organizations which do not evolve will succumb to the economic forces from their competition and the technical debt that their development teams stack up as the years go on.
One thing that will kill any movement towards improving a team’s productivity is a leader who shoots down good ideas by listing out why it is hard to accomplish. Leaders must be bold, set the requirements, and figure out how to make the impossible possible. Organizations which do not evolve will succumb to the economic forces from their competition and the technical debt that their development teams stack up as the years go on. Leaders must have the vision to foresee those dangers and do what they can within their jurisdiction to ensure those threats do not gain a foothold in their area of specialty! Every leader should spend a few minutes a month and look at the feedback given on sites like Glassdoor and see where there may be some areas of concern that need their undivided attention. It’s this type of leadership that companies need today — so be that kind of leader!
How Federal Agencies Do Knowledge Transfer
When you get to a new position at virtually any intelligence or law enforcement agency, you have a period of time to become certified in that position. You get a list of topics you must have someone more experienced explain to you or you gain the knowledge from reading documents, and tasks that someone experienced must train you on how to properly do them. Once you’ve been trained and you feel confident enough that you can display your knowledge and ability to do a given task at the level it was shown to you, then you go to another certified person and show them what you know. Then they sign you off on that item in your certificate list. Once all of the items have been signed off, then you have a “murder board” or final certification assessment that, when successfully completed, will earn you the title of being certified. In these agencies, we called this knowledge transfer model Position Qualification Standards (PQS) or Job Qualification Requirements (JQR). Once done, the general knowledge, apparent experience, and ability was homogenized and the quality of the product was high, productivity was high, and job satisfaction was also high.
How Knowledge Transfer Looks For Development Teams
Professional developers document your code. Document your code!
KT is a multilayered discipline that incorporates several common-place methods of maintaining institutional knowledge. The high points are as follows:
Inline Comments
Yeah, I don’t buy the argument that adding comments in code equates to bloat. In compiled languages, comments are stripped out, so don’t worry about comments adding to your app’s size, nor do I think that if comments are written correctly, they detract from easily navigating your code and following it’s flow. In fact, it should improve it! Comments should serve as summaries for sections of code, just as if turn-by-turn navigation is a summary of one’s drive from the house to the office and back.
Source Code Documentation Blocks
If you don’t document your code, then you are doing it wrong. Okay, I sound opinionated to some of you…and I’m okay with that. The point is to document your code so that you can improve Developer Experience (DevX) and lower the cognitive load for your development team. Referencing quick documentation from Apple’s IDE is common-place among seasoned iOS developers. Writing, maintaining, and referencing JavaDocs is common-place among seasoned Android developers. Professional developers document your code. Document your code!
The Wiki
Professional development teams maintain a Wiki, either in Confluence, an on-premises directory of markdown files, or a Wiki in a remote repository with Bitbucket or Github. Wikis are priceless if done correctly. It will be easily navigable if you are doing it right. If no one uses it, then you are doing it wrong!
Formal KT Process
This is how federal agencies do things. If your team is in the financial or medical sectors, then this process is for you! Heck, even if your team is small and not handling Personally Identifiable Information (PII) or handling HIPPA protected data, your team would still benefit from a formal KT process. This process, coupled with the above examples are the key elements to building a solid knowledge base among your pool of developers.
So, you might be saying at this point Hey, thanks for all that theory, but you’ve gotta give me something tangible here! Well, here is an example of the Formal KT Process:
Closing Thoughts
KT must be incorporated into the SDLC. KT must be a step in the cog, just like QC Tests and Release are.
In many positions with the US Government, we used a similar list, albeit, the content of the list was different. The point remains — transfer institutional knowledge from those who know to the one who is not expected to know. The list I’ve provided is just a sample. For your team, you might not need to hit all of those topics. You might even want to expand upon the list. My recommendation is to combine reading materials with live, in-person KT time. We are not talking about an hour discussion. Perhaps 5–10 minutes for an entire section. Use it as a guide.
KT must be incorporated into the SDLC. KT must be a step in the cog, just like QC Tests and Release are. KT should be taken seriously if a team is to become more productive. KT is a MUST for teams with high-turnover. If you want a rockstar development team and maximize your team’s product quality, then be the leader and advocate for better! Cheers!
About The Author
Mark Filter is a mobile application Developer at a Fortune 50 company, formerly the Lead Mobile Application Developer for Family Dollar/Dollar Tree Inc, and develops native iOS and Android applications in Swift/Objective-C and Java/Kotlin. He earned a Bachelor of Science in Mobile Development from Full Sail University and in Interdisciplinary Studies with concentrations in Math/Physics, Computer Science, and Behavioral Science from NYIT. He served in the United States Navy for 13 years as a nuclear weapons inspector and diplomatic interpreter. When he is not writing code, he is … forget it, he is always writing code.
