If we lived in an ideal world, it would be easy to imagine that your company has an IT team of perfect and strong members. Everyone knows their job very well and they do it without delays and difficulties. However, in the real world, most often there is a team where there are one or two strong employees who can instantly "extinguish the fire" in a project and have all the knowledge to solve a customer’s business problem. But what if such an employee takes a long-term vacation or decides to leave the company altogether? Then you have an urgent priority - the transfer of knowledge.
This transfer knowledge process involves gathering as much information as possible before the employee leaves. It may be fearful due to urgency and a short amount of time. But it is not necessarily a complicated and heavy process. Step-by-step strategically you can implement all the procedures to solve this situation.
Remember that a knowledge transfer program helps you develop and manage team members. But it can also help you streamline processes and increase productivity.
Here is how to execute an effective knowledge transfer process.
First things first
Knowledge transfer is a strategy that involves capturing and sharing critical knowledge within an organization.
When it comes to learning, there are two types of knowledge:
- Explicit knowledge is information that is easily shared and obtained through speaking or writing. It can be easily picked up from various sources: talking to someone, reading books, watching online resources, etc.
- Tacit knowledge is a set of hard skills and experiences that people can't pass along without sharing.
Both types of knowledge can play a role in transferring knowledge, but the most important type of knowledge to capture is tacit knowledge.
We mentioned a step-by-step solid strategy, so let’s start.
Key steps in the knowledge transfer plan
Step 1: Define what knowledge to collect
The key to effective knowledge transfer is identifying what information you need to collect from various sources.
Here is a checklist that serves as a framework to collect the basic essential knowledge items from various levels.
- Repository URLs with access details
- Access to the systems and existing environments
- Key algorithms
- Specification of classes and app’s layers
- Deployment guidelines
- System’s configuration and installation
- Software development tools and techniques
- Operating instructions
- Bug tracker data
- Software development workflow
- CI/CD best practices
- Branching strategy
- Business requirements
- Architecture documentation
- Database structure design
- Mockups and graphics
- User stories
- Test cases
Remember, these points may differ depending on the functionality of the project.
Let's draw an analogy with a game. The docs and code source are amount of playing cards. And now we need to go to the players.
Step 2: Define people who transfer and receive knowledge
Once you have identified the knowledge that you need to collect, it’s time to contact the people who could provide the necessary information on each level. These include the people who could help you obtain the necessary information on each level:
- Organizational level – Delivery managers, engagement, legal, finance department members;
- Team level – CTO, project managers, etc;
- From expert to expert – QA engineers, UX/UI specialists, DevOps engineers, software developers, etc.
Sometimes the project allows you to select one responsible person who is aware of and can onboard on all processes. But in the case of a long-running project with a large amount of data with a background of several executing teams, most likely it will be necessary to involve all participants.
So, we have selected the number of cards and players, now you can go to the game rules.
Step 3: Choose knowledge transfer methods
There are five the most effective methods for transferring knowledge. These methods were proven by our PMs in real project conditions.
Project documentation is the most efficient way to pass knowledge between team members. However, it can get outdated very quickly. It should be kept current and always be updated.
- Face-to-face QA sessions
It is useful to have direct communication to discuss essential features of the project. But there is the other side since meetings can be very confusing for the new member. So they should be focused on small portions of the knowledge that the person passing it needs to digest.
You can assign a mentor for a new member. A mentor is typically a senior developer with in-depth expertise in various development tools and projects. He or she has the ability to teach, explain, and motivate. So, a mentor can guide the onboarding process, provide detailed feedback and recommendations after every milestone of the project.
No company can make it mandatory, but it could be useful to tie it into performance. When people volunteer for mentoring, make sure they're acknowledged for their efforts.
It is an agile software development technique. This method works when two programmers work together, even on one workstation, on a development project. The one person carrying out the coding explains his or her actions, while the other programmer watches and adjusts the process. It perfectly fits for transferring tacit knowledge.
- Code reviews
Team members check the code written by their colleagues for any errors or inconsistencies, and it can help them improve their skills. It also serves as an additional way to improve the quality of the code. Code review helps teams keep track of all the hidden knowledge in the code base, and it also helps new members get a fresh perspective on certain parts of the code.
So, as was mentioned above, each of these methods is a card game with its own rules. And when you decide on it, the number of cards and players, feel free to start. It is important to note that this is not a classic game of winners and losers. We're talking about the concept itself.
And now it would seem that this can be finished, but there is one more important step.
Step 4: Measure the results of success criteria
The final step is to assess the effectiveness of your knowledge transfer plan. Set up QA, use team-wide platforms, arrange meetings to check the strongest and weakest sides of your chosen knowledge transfer strategy. You can analyze how quickly your team has started with the knowledge transfer process. The velocity of the knowledge transfer is the most critical metric to evaluate the success of an information transfer. Later, you will be thankful for this step. For example, at the moment when your business will be massive and influential and you will need to create a new team of developers. It will save you money and streamline productivity.
Each company is painfully familiar with the scenario when a change occurs in the team and one employee must take the place of another. It may be an existing employee, or it may be a completely new one. Like in mathematics, changing the order of summands doesn’t change the sum. So, the result of the project must not be different with changing the developers. This is where effective knowledge transfer comes in to minimize waste and not affect product quality.
Knowledge transfer for the software team is achieved by identifying the right people, processes, and products to deliver the right results. It involves continuously improving and learning.