Each software development team has its own unique ecosystem that relies on methods for coordinating tasks and transferring knowledge between team members. The latter is especially important when onboarding new engineers, whether contractors or in-house developers. A structured knowledge transfer process ultimately helps concentrate each employee’s knowledge into a single company knowledge base to decentralize teamwork and provide easy access to all information for new hires and existing employees.
This article focuses on three main points:
- Knowledge transfer methods used in software companies
- Two types of knowledge and their impact on the development process
- Why building self-sufficient teams is more effective for fast-growing companies than a well-defined learning and knowledge-sharing process.
Why Knowledge Transfer Is Important
Software development is a knowledge-intensive process in which knowledge is created and shared between the team and external stakeholders. However, a fuzzy, unstructured knowledge transfer process can lead to inefficient development. In the worst case, the departure of key employees who own all the knowledge can bring a project to a halt.
In contrast, having a knowledge-transfer plan will help disseminate knowledge, decentralize the team’s work, increase productivity, and streamline training for new employees. The benefits of such a plan include:
- Effective dissemination of project knowledge, domain expertise, and technical experience between developers
- Consolidating the knowledge of distributed employees into a single company knowledge base
- Improving the onboarding experience, which sets the pace for the entire employees’ journey at the company
- Retaining knowledge that would otherwise be lost due to the departure of experienced engineers
- Continuous improvement. When knowledge is readily available to all team members, it is easier for them to improve their skills
The Difference Between Tacit and Explicit Knowledge
Knowledge embedded in an employee’s mind through experience and work is called tacit knowledge. It includes technological expertise, industry knowledge, and business judgment and is transferred mainly through direct contact between people. Examples of this are pair programming sessions or one-on-one meetings.
In contrast, explicit knowledge is information that has already been codified and digitized in documents, spreadsheets, reports, and coding standards. Therefore, it is easily accessible to any employee and can be used asynchronously.
The knowledge management strategy in software engineering depends on the development method. For example, agile development relies heavily on tacit knowledge, which is difficult to transfer to another person through documents and images. In plan-driven development, on the other hand, employees rely mostly on explicit knowledge because the people-to-document approach makes the most sense.
Documentation Is Still Vital for Any Agile Business
The Agile Manifesto values people and interactions above processes and tools and working software above comprehensive documentation. However, if the project manager and engineering team store all the important information in their heads, details can get lost in communication. Meanwhile, a software project with excellent documentation depends less on the people working on it, so it’s more resilient to unexpected changes.
Alistair Cockburn, one of the pioneers of the agile movement in software development, wrote that it is an art to guess how much can be bound in the company’s oral tradition and how much has to be committed to archival documentation. In contrast, Haridimos Tsoukas, an organization and leadership theorist, believes that tacit and explicit knowledge are two sides of the same coin. The scholar remarks, “a map, however complex, cannot read itself; it requires the judgment of an experienced reader who will relate the map to the world.”
In other words, explicit and tacit knowledge coexist, and it all comes down to getting the proportions right. We believe this is possible through communicating with existing team members. Feedback on which knowledge-sharing methods helped them the most will determine the new employee onboarding process.
Why Interactions Are an Integral Part of Knowledge Transfer to a New Hire
One purpose of onboarding is to transfer the knowledge base to the new team member. Another goal is to integrate the employee into the organization’s structure and vision.
Forty-six percent of professional developers call a coworker or friend when they get stuck on a problem, and new hires are no exception. By getting a mentor, the developer is aware of other colleagues’ areas of responsibility and technical experience. Daily meetings are also a great way to sync up with the state of the project. The new developer will know the range of tasks other members are dealing with and who to contact if they run into obstacles.
Finally, one-on-one meetings with the team leader will help identify any remaining questions, concerns, or problems they face and ensure a smooth knowledge transfer process.
Effective Knowledge Transfer Methods and Techniques for Software Developers
Assigning a Mentor
Assigning a personal mentor helps a new developer learn faster and facilitates the first personal connection on a new team. Face-to-face conversations with a specific team member are also useful for newcomers who find it difficult to get to know all the members at once during the first days of onboarding.
A particular question is how to identify potential leaders in the development team. Usually, a mentor is not just a person who understands documentation and business logic. It should be a senior developer with extensive expertise who can motivate others to succeed and brings solutions to the conversation.
Pair Programming Sessions
Pair programming is a development technique in which two engineers use the same workstation to write code. Developers working in the same office use only one computer and one keyboard.
Remote teams use screen sharing tools such as the Live Share extension for Visual Studio Code or shared terminal environments such as a combination of SSH and tmux. These options allow multiple developers to collaboratively edit and debug code in real-time while in different locations.
The key benefit of pair programming is that a new hire works on real problems together with an existing expert. The new employee learns how the existing engineer organizes their source code, how they name variables, and how they solve problems. There is knowledge that can only be learned through experience.
Meanwhile, AI comes on the heels of senior developers teaching newcomers through pair programming sessions. For example, GitHub Copilot accepts a comment describing the logic a developer needs and suggests code based on the project’s context and style conventions.
As Atlassian noticed, code reviews help facilitate conversations about the code base. Existing engineers mentoring new participants help them uncover hidden knowledge within the code. Moreover, a code review (like a pair programming session) is not only a mentoring exercise. It should go in every direction, so that a newcomer with a fresh look will uncover clumsy code fragments or deliver a different point of view.
Also, one of the main purposes of code review is to decentralize the team’s work so that no one person is the only one who knows a specific part of the code base. This knowledge-sharing method is vital because it won’t take the company by surprise when an engineer goes on vacation or quits.
Team leaders conduct one-on-one meetings to set expectations and introduce the company and its culture to a new hire. Such meetings are also necessary to learn how the developer onboarding and knowledge-sharing process is going.
The team leader should ask if anything is confusing or unclear and if the new employee has all the information they need to perform their tasks. Talking about these things will ensure a faster knowledge transfer to the new developer.
Documentation helps the person working with the software understand its features and functions. FreeCodeCamp suggests dividing documentation into two categories: process and product documentation.
Process documentation may include test standards and schedules, project plans, timelines, and meeting records.
Product documentation describes the actual software the company is developing. It comes in two forms: manuals for end users, system administrators and support, and system-related documentation for new and existing developers. The latter may include:
- Product requirements
- Overall design and architecture
- Key files within the application
- Explanation of functions and subroutines
- Description of key algorithms
- Release notes
Since most people are visual learners, documentation should include visual content such as illustrations, flowcharts, or video tutorials and avoid long blocks of text.
Comments are used to describe the programmer’s intent or explain rarely used optimizations and constructs which may not be immediately obvious. When a new person has difficulty reading the code, the program can’t be maintained, updated, or reused.
However, programmers argue whether a bad comment is worse than no comment at all. For example, Stack Overflow advises against writing comments that duplicate code. Instead, they should dispel confusion, explain unidiomatic constructions, and provide links to the original source if the code was copied. Developers should also add comments when fixing bugs or marking incomplete implementations.
Online Tutorial With Exercises
Custom-designed exercises help newcomers familiarize themselves with the company’s infrastructure and best practices. Startups and small businesses are unlikely to invest the time and resources to implement such training programs, but they are common in large enterprises.
For instance, Google has Codelabs, an environment for a guided, hands-on coding experience of building an application or adding a new feature to an existing application.
A comprehensive knowledge base and mentoring system can accelerate the onboarding of a new specialist or facilitate a complete change of team or software vendor. However, having a well-defined training and knowledge-sharing process is not always the most important thing if a company is growing quickly and experimenting a lot. There are times when an employer assigns a new professional a fundamentally new task that neither they nor their colleagues have done before. In this case, they will look for solutions on Google or ask questions on Stack Overflow and then try several options and run diagnostics.
That said, such challenges only strengthen employees’ self-sufficiency. After all, teams will never become truly high-performing if they depend on a team leader or senior developer for everything. The more developers build themselves while making collaborative decisions with their colleagues, the faster they can reach new levels of success — as a team.
For more information on employee onboarding, check out our step-by-step guide to help companies prepare for the remote developer’s first day and make sure the adaptation goes smoothly.