Knowledge Sharing in Software Engineering Teams
… is not just for improving technical proficiency
You know the drill. A new engineer joins the team, they get assigned their first task and they are pointed to a bunch of documentation on how to setup their environment and how the codebase is structured. “If you need any help, let X know” is probably what follows, and the poor guy is left to their own devices.
Technically speaking, you have just shared some knowledge with the new guy. You also missed an opportunity to help them integrate with the team, and you haven’t really set them up for success on their first assignment. But let’s take a step back.
First of all, let’s make sure we are on the same page on the meaning of sharing knowledge. Sharing knowledge is not the same thing as documenting it, and then sharing the documentation.
Documenting knowledge is not the same as sharing it
Documentation is passive. Sharing is active. Sharing requires two or more people to sit down together and interact over a piece of information. It’s kind of like mentoring / tutoring, except for the directionality of the knowledge transfer: sharing implies that all the parties involved have a chance of learning something, whereas in mentoring you have an instructor imparting knowledge, and a learner acquiring it.
Now, I am not advocating that documentation is useless. Don’t get me wrong. Documentation is good for reference, especially when designing or developing new components, but it’s not the be-all and end-all of the knowledge of your system. Also, it has a tendency to become outdated pretty quickly.
Besides, there are some nuances that are difficult to capture in documents, and that we usually put down as experience with the codebase. Knowledge sharing can help to ensure this experience spreads across the team.
Sharing results in better teamwork
However, knowledge sharing is not just about technical proficiency and training. As human interaction is involved, the team learns to work more closely together. Trust and mutual respect grow as the components of the sharing group help each other reciprocally, and people learn more about each other’s working style, strengths and weaknesses.
In short, knowledge sharing sounds like a win-win, and for the most part, it is. At least, this is the case when it’s done properly. Otherwise, the experience itself might be frustrating for the team, with learning outcomes affected by a fall in belief in the system.
Without further ado, let’s look at some effective methods of knowledge sharing that I have used in the past, and how they can help your team grow.
Effective methods of knowledge sharing
Sharing Sessions
Best for: Remembering lessons learned¹; avoiding making the same mistakes over and over again
Ideal group size: The larger the better
A sharing session is a meeting where the team shares what they have learned (from the codebase) with each other. It can be structured around a specific project/activity/topic, or a time period (e.g. a week, a sprint). Regardless, you want to make it something that the team looks forward to, or it won’t be as effective.
Here are some tips to make it more enjoyable for the team.
Schedule it away from “core dev time”
As an engineer, you don’t want to be interrupted when you’re in the middle of something. Context switching is expensive time-wise. Therefore, it’s better to schedule these sharing sessions away from core development time so to increase the team’s intellectual engagement.
“Core dev time” might vary from engineer to engineer, especially if you operate under a flexible hours arrangement, or if the team has some remote members. Lacking a common indicator of downtime, the following are good timeslots:
- After lunch, if your team has a somewhat fixed lunch break
- Friday, towards the end of the day, as a good way to close up the week before the weekend (assuming a Mon-Fri working week)
Don’t wait for lessons learned to go stale
When scheduling by sprint/project, it’s worth to have the sharing session soon after code completion, so that the lessons learned are still fresh in the engineers’ minds. The longer you wait, the less likely the team will remember what they learned.
Don’t blame
It’s easy to blame existing code, or the apparent ineptitude of an engineer (or yourself even, when presenting your own lesson learned), however this discourages further sharing and reduces the importance of the meeting to a petty bitchfest. Remember the final goal here is to learn how to get better, not how things are or have been, bad.
Make it interactive
Sharing the lessons learned is only half of the equation. The other half is addressing questions/concerns from the team. Knowledge sharing works best in the form of a discussion / Q&A session, although moderation is required to avoid making the session go off-topic, or becoming too long-winded.
Brainstorming Sessions
Best for: Identifying possible solutions to a problem while learning from each other
Ideal group size: Medium, less than 10 people
Whereas sharing sessions look at solutions after they have been implemented, brainstorming sessions deal with the problems the team is currently working on.
The common outcome of a brainstorming session is a solution to a roadblock or a proto-specification for a system/project. What is often forgotten is that brainstorming sessions are also a great way to share knowledge between team members.
In order to favour knowledge sharing during brainstorming sessions, we can look at implementing the following guidelines:
Check the ego at the door
In a brainstorming session, all ideas are equal. Each engineer should be prepared to defend their solution, but at the same time have enough open-mindedness to recognize the advantages of proposed alternatives.
Being humble in spite of years of experience or seniority can help softer voices to be heard, voices that would otherwise be drowned by more self-important team members (and there are always some).
Allow for preparation before the meeting
A brainstorming session works much better if all the people involved had a chance to do some preliminary investigation on the problem in their own time. Better still, investigation time should be properly reserved to ensure each participant give it enough importance in their otherwise busy schedule.
Allow for an audience
Not everyone needs to be an active participant in the brainstorming. There’s much benefit for somebody who’s less experienced or newer to the team in joining a session as an observer. They will pick up concepts the rest of the team might have taken for granted, as well as learn the glossary specific to your team/organization.
It is also a good way for engineers to self-evaluate their knowledge of a system/project, and to get to know more about areas of the codebase they might not be too familiar with.
Pair programming
Best for: Sharing specific knowledge on a restricted portion of the codebase; cross-training the team
Ideal group size: Two or three people
Some engineers see pair programming as a waste of time. Generally speaking, they are not too off the mark. You basically cut velocity in half by getting two people to look at the same problem.
However, pair programming can be very useful in two specific cases:
Help new team members to get up to speed with the codebase
Let’s say an ace has just joined your team as a fresh graduate from a top university. Realistically, they won’t be productive from day 1. It will take them some time to learn the ins and outs of your system and learn its architecture, whether good documentation exists or not.
You can leave them to do this learning alone, as we have seen in the opener for this article, or you can pair them with somebody more seasoned and get them to hack at the problem together.
By doing the latter, the new member will have a chance to use their skills from the get go, and will become independent more quickly. Do you really lose that much velocity if this happens?
Reduce the risk of errors when implementing critical code changes
This is the good old “four eyes see more than two” adage. As an engineer, you usually need to juggle a lot of details in your head when writing code. Inevitably, the risk of overseeing minutiae increases alongside the complexity of the task you are working on.
In the case of critical components, pair programming can reduce the risk of introducing obscure bugs because of the complexity of the code involved. Of course, it takes the right pair of engineers to pull this off. There should be mutual respect and appreciation of each other’s skills, and enough humbleness and trust between the people involved.
The end result is also increased knowledge of the system, as the mini-team learns from each other’s specific knowledge of the system.
Note how all of these techniques are based on the interaction between team members. Interaction is important to keep the knowledge alive and current, as well as building trust. These are the key outcomes we are looking for when implementing a knowledge-sharing strategy.
Conclusion
Thanks for joining me today in this quick exploration of knowledge sharing.
Whenever you do a sharing session, a brainstorm or a pair programming activity you are not only learning more about the codebase; you’re also learning more about the rest of the team, how they think and how they approach problems.
You’re helping others and they’re helping you, building trust and mutual respect. This, in turn, makes sharing knowledge easier and more effective as time goes by. New engineers integrate into the team more quickly, and they learn to apply this methodology going forward, not just within your organization but in their future gigs as well, five or ten years from now.
Velocity-wise, the decrease incurred by introducing these activities is usually offset by a reduction in training time and in bugs introduced.
Ultimately, knowledge sharing done right helps your team grow and, with it, every single one of its members.
That’s it for today. Hope you enjoyed the article, and it has given you some ideas on how to implement knowledge sharing in your team. If you would like to discuss this topic further, feel free to leave a note in the comments and I will be very happy to engage in a conversation.
Till next time, keep on making great software!
Footnotes
[1] Lessons learned: unforeseen circumstances that arose during development, and how the team solved them.
