In the dynamic world of IT, where people come and go and clients demand more and more features, the need for knowledge transfer between the developers turns out to be critical. Even short-term projects with fewer functionalities need to be supported, and if there is no documented knowledge, that task turns out to be left in the dark.
So how does knowledge transfer work?
When discussing knowledge, we have two main goals — gathering it on one side and dispersing it horizontally and vertically throughout the organisation. If your company is a conditionally hierarchical structure, knowledge is being transferred between the employees in different teams on one side and between the layers of management on the other. As you can see in the figure below, even in a simple organisational structure, communicational channels could be dynamic.
Sharing information between employees is essential, especially if it concerns procedural or product knowledge. In my previous article, we discussed the importance of knowing how different aspects of data contribute to a company’s overall progress. So, suppose you have a stable onboarding process with many examples and documentation. In that case, your feeling of being integrated and accepted is increased, which leads not only to better integrated intellectual capital but also encourages you to establish knowledge sharing as a tradition in your work style.
Examples:
Client 1:
The onboarding process was two weeks, and all teams were included. That gave me a significant overview of the product, the main domains and subdomains, and the architectural style. We also discussed each service’s code structure, external services, and critical initiatives. When I was offboarding, I tried to include those practices when introducing the new employee. This gave me the opportunity to update existing documentation and fill knowledge gaps that had been previously underestimated. Ultimately, both sides were satisfied, and we continued communicating afterward.
Client 2:
I was included in this project in the final stage of development. Most of the functionalities were developed, and some use cases needed to be finalised. The onboarding process was focused on how to work with the platform and what are the prominent cases we will develop. One of the crucial aspects was the Quality Assurance on low level and documentation. Code complexity required some additional clarifications. A unit-testing strategy was critical to be defined in order to have some direction during the QA process. My final feeling was that seeking information and initialising conversations with your colleagues from the beginning of your presence in someone’s working environment makes you dedicated enough to have a productive time during the project and loyal enough to bring the project to its logical closure.
In terms of communication between different layers, we can separate knowledge types into organisational and technocratic — both contributing to the mission and vision of the company (know-why) and the technological profile it defines (know-how). Lacking that kind of knowledge would be a blocker when introducing new employees. The main idea of onboarding is to ensure you understand the values that drive the company towards its goals and find your place in the team, where you will be helpful and creative. This may not e critical during your first year, but the more you grow, the more you will want to understand how the magic is happening.
Conclusion
Knowledge transfer is not something strongly procedural. The best environment is where knowledge transfer is established naturally, where people have a tradition to communicate and grow together as a team, so even at the end of your journey, you will keep great memories and friendships.
Dilyan Georgiev — C# .Net Developer at Lexis Solutions, Knowledge Management PhD
Top comments (0)