We all know knowledge transfer is key to building a kickass software developer team, but among many pressing issues, knowledge transfer is one of the first things that will be put aside when a burning deadline is approaching.
But, the problem still stays here: knowledge is unevenly available in your team.
Most software teams are composed of developers with different knowledge levels, including different domain expertise and programming experience.
Your team could get new developers at various stages of the projects and sometimes even in the maintenance phase. New team members can struggle to assimilate the necessary amount of information to perform their job effectively. Even with smoothly working knowledge transfer techniques, it takes time.
Senior team members have significant role in knowledge transfer but typically they have less time available and their time costs the most.
Due to the limited time and resources, finding the most effective methods of knowledge transfer is crucial.
This blog post is here to help.
We conducted short interviews with tech leaders, asking them about the most effective knowledge transfer techniques.
The result is a list of methods spiced up with some practical tips.
Since every team dynamic is different, finding suitable knowledge transfer methods takes experimentation and some time.
I’m sure by putting the knowledge transferring techniques mentioned in this post into practice, your software team will get more effective.
You might have more pressing issues.
If your team suffers a high fluctuation rate, then the first and most important thing is to fix it.
Just think about it. It doesn’t make sense to pour water into a leaking bucket.
It doesn’t make sense to put a lot of effort into knowledge transfer when within a few months, you will see your team members leaving.
The fluctuation rate needs to be decreased in order to keep good employees longer and to transfer as much knowledge as possible to other team members.
Without a great work environment, it will be damn hard to attract and keep talented people. The first step you should take is to figure out the reasons why your team members are unhappy and the reasons why they’re leaving your company.
Address these first.
To help you out, here are some tests to figure out if your team members are unhappy in your team:
Read this short story from Steve Bockman.
Steve hosted a workshop that let participants experience three different forms of knowledge transfer methods in a production environment.
In this case, the product was a paper plane with an unusual design.
The idea was to try different ways of transferring knowledge about how to build paper airplanes to get an unusual design and to compare the relative productivity of the different methods. These methods were the following:
Using the documentation method, only one person out of 8 came close to building the airplane within the allotted 5-minute period.
Using the reverse engineering method, 1 person out of a total of 4 completed the airplane within 5 minutes.
Through mentoring, each of the 4 team members completed the airplane in less than the 5 minutes available.
However, this experiment involved only just a handful of people, so it did not reach statistical significance. Even the experiments weren’t separated properly, but it indicated that face-to-face collaborative ways are more effective when it comes to knowledge transfer.
Face-to-face knowledge transfer (such as mentoring) probably takes more senior people’s time than just sending over documentation. But what really matters is the whole team’s productivity in the long-term.
Check out this guide on keeping up with tech trends and improving as a manager!
The biggest problem with documentation is that it becomes outdated super-fast. Team members not only need to create it but also to keep it updated.
Make as few things as possible with the need to be documented by fixing bugs, making your software easy to understand (inline commenting, following industry standards).
Focus on using as many external training resources as possible, many of which are free or for a few bucks, to learn things that are not unique to your product (coding best practices, security, database design etc.).
Making every team member familiar with the project and giving feedback on the code team members wrote. This also prevents the project from being fragile since more people are familiar with the code base. Code reviews pretty effectively distribute project-specific knowledge across the team.
Often, teams have hidden knowledge within the code that surfaces during code review. Newer members, with fresh eyes, discover gnarly, time-plagued areas of the code base that need a new perspective. So, code review also helps ensure new insight is tempered with existing knowledge, just make sure to get the right tools.
Code reviews stimulate conversations around code structure, style, and architecture as a natural part of the workday.
Pair programming is an agile software development technique in which two programmers work together at one workstation to solve a development problem.
During pair programming, one person codes and the other inspects the process. The typing person should explain what he is doing and why.
Pair programming is a form of mentoring. This interaction is the crucial part of the process and makes it really effective to learn with fast feedback loops.
With the pair programming technique, knowledge is easier to be transferred. Not only is domain knowledge shared, the system’s code can be easier to inspect and refactor.
Here are six strategies experts combine to guide and teach novices in peer programming sessions:
Brown bags refer to the situation where people bring their own launch (usually in a brown bag) and eat their food together while getting to know each other and exchanging knowledge.
A brown bag lunch (BBL) allows team members a real-time exchange of knowledge and experience. It allows developers to socialize and get to know each other in a relaxed situation, and solve problems while it promotes learning and trust building.
It is also common while the team has lunch for someone to get up in front of a whiteboard and talk about some topic. It’s a great way to learn something in an informal way so people tend to feel more comfortable asking questions.
BBL is a form of peer teaching spiced with team lunch.
This is not really a product specific knowledge transfer but it is a great way to learn best practices from more experienced developers and to get familiar with new technologies.
Hackathons are great examples where teams have a limited time to ship a working product. This forces team members to learn fast and be as productive as possible while having fun.
One of the biggest advantages of hackathons is that developers not only need to learn about new technologies but they also need to apply what they have learned.
We had a successful experiment with Lean Poker, an agile training method that doubles as team building.
Mentoring developers is both common and rare in the software industry. Many people actually do it, but most of the companies don't put emphasis or effort into setting up a mentoring program, so most people don't even realize it.
However it's extremely useful, and developers on any level or stage in their career can profit from being both mentors or mentees.
No company can really make mentoring mandatory and make it work, so a useful practice could be to tie it into performance. Recognizing the extra effort people put in by mentoring others at a promotion discussion or a performance review is the best way to make sure potential mentors get something out of helping others.
However, face-to-face knowledge transfer seems to be more effective; the method you apply depends on the workload your team is facing.
Do you want the person to learn in the fewest amount of days, or do you want them to learn with the least amount of impact for the current schedule?
If you want the person to learn in the fewest amount of days, pair programming could be the best option.
If you want them to learn with the least amount of impact to current schedule peer (team) code review, documentation reading (if you have any) and brown bag lunches could work.
In this post, we provided some insights from other tech leaders. Your next step is to take action and figure out the most effective way to transfer knowledge in your team.
The trick is to find the right combination of the different knowledge transfer formats that suit your team.
Some amount of documentation might be helpful, but solely relying on documentation would yield limited benefits.
You can purchase courses that help new developers dig deeper in any topic that’s not unique to the project/product, but the hardest things to transfer are the best practices and soft skills that are in your senior developer’s head.
The most effective ways for knowledge transfers are the ones that require face-to-face interaction and allows fast feedback loops between your team members.
🍔 Hungry for more?
👉 Is Hiring Developers a Challenge? Here is How Tech Companies Came Over it
👉 A Scientific Way to Prioritise Software Development Requirements
👉 10+ Startup Tech Leaders Reveal How They Prioritise Software Development