According to
2023 DORA report, knowledge sharing has a positive impact on software delivery & organizational performance. An effective
knowledge-sharing process is a balanced combination of both tacit (oral transmission) and explicit (codified & written) sharing, where questions are answered once, and the information is available to others; it’s a process where
capitalization is key (share with the most).
A culture that supports knowledge sharing boosts each engineer’s learning curve, consolidating job satisfaction. As
tech leaders, you & your team experiment with daily situations with missed knowledge transfer opportunities. If they sound familiar, it’s a chance for you to adapt behaviors to make the most of these situations. It’s worth to give a shot!
1. Missed opportunities to elevate during code reviews
An efficient code review process leads to code improvements, knowledge transfer, shared code ownership, and team ownership. But they have two limitations: 1) code reviews remain in a 1:1 conversation scope, restricting the scope for the value of the discussion 2) There are regular debates about coding standards, which should involve the whole team. So, while reviews should ensure no major defect is pushed to production, they lack capitalization from the developer’s discussions about the code.
To overcome these limitations, keep the code review focused on checking major issues and catching relevant and meaningful comments or topics. This content should be reviewed
collectively during a
synchronous meeting with your team to thoroughly review each point, explain different concepts, share knowledge, or reach a consensus about coding practices. Don’t create bottlenecks to deliver value to your customers and postpone technical discussions.
2. Missed opportunities to learn from bugs
If software engineers fix bugs on their own and don’t share more content with others, you can bet someone else will struggle in the future to do the same work. Consequently, time will be wasted to identify the bug, devoting effort to fixing it, and probably reinventing the wheel, which frustrates everyone. We all make mistakes, but we should capitalize on them to avoid seeing them again.
To save a precious amount of time, we can dive into the
Dantotsu methodology to prevent defects from happening again. This is based on a sharing session about why defects occurred (their root causes), how they were handled and fixed, and what countermeasures have been implemented to reduce the risk of seeing them again. It’s not about blaming people, but to collectively progress by learning from our mistakes. The Dantotsu philosophy brought many benefits in Toyota’s factories.
3. Missed opportunities to highlight code improvements
Assume you made a fix that drastically improves the runtime performance, adds an extra security layer to an API, or updates the CI/CD pipeline to add new quality checks. These changes are worth showing to the whole team so that all developers become aware of them to grow their codebase ownership and knowledge. And code review won’t fully help since it usually involves one reviewer. So, most engineers will miss this value.
To share this valuable content, you can post a thread on your messaging platform (Slack, …), but you’re likely to be read by a minority of people (we’re often surrounded by notifications & emails to read, so we have limited attention). The best chance you have is during a synchronous meeting with your team, where you can browse any technical topics, such as discussing your coding practices.
4. Missed opportunities during newcomer’s onboarding
Developers may need up to 7 months to reach optimal productivity. During onboarding, knowledge sharing should happen at a high throughput. The ramp-up will be optimized if people can get the answers they need without pain. Suppose teammates are unavailable or don’t invest enough time in this process. In that case, the whole team will pay for that: the newcomer won’t feel integrated, and code issues are likely to occur, meaning a rework and a longer time to delivery.
To ensure a great onboarding experience, recruits should have access to both tacit (during informal meetings, pair programming sessions, code reviews.) and explicit knowledge (codified information in your knowledge management system). It helps to learn in both synchronous and asynchronous ways. For instance, if you document your coding standards, a tool like Packmind helps new engineers to become quickly familiar
with them.
5. Missed opportunities to fix outdated documentation
While looking for a technical answer, you encountered many README files or wiki pages without success. Finally, after a few hours of searching, you can figure out how to resolve your problem. That’ll be a great chance to update this knowledge so that people will easily find the right answer next time. Still, people don’t always take this opportunity and prefer to say, “
If someone faces this problem later, I’ll remember the solution”. Of course, two months later, you probably forgot how you made it. Skipping this chance will again make people waste their time.
First, if there is too much outdated knowledge, you should reconsider if the repository used (e.g., wiki) is the most relevant for the use cases. If it’s a technical procedure for installing software, you should remind everyone that it truly matters to keep this documentation up-to-date. If you address coding standards, it’s been observed that generic wikis
have limitations since they’re disconnected from developers’ workflow. In any case, you should set a smooth process that is not felt as a burden by developers.
6. Missed opportunities during pair programming sessions
Pair programming helps reach a better result sooner, fosters interactions with other developers, and catalyzes learning. This practice can be extended to mob programming involving the whole team. But it’s rare to observe teams practicing full-time mob programming in 2023. Similar to code reviews, knowledge-sharing is restricted to the scope of participants, and there are missed opportunities to share with others or beyond the team.
To avoid repetitions through each session, define a process where you 1) identify and catch relevant technical discussion you’d like to bring beyond the pair programming session 2) review and discuss them with more participants later during a dedicated meeting. If you work in Mob programming, think also beyond your team. We bet you’ve got valuable knowledge to share with other teams in your organization.
7. Missed opportunities when sharing conferences, books, or blog posts
Developers can learn from blog posts, attend meetups or meetings, or watch their replays in videos. If a group of developers has the chance to go to a Tech event, they’ve probably seen many exciting talks, so how could these 2-day conferences benefit to others in the teams? Similarly, If you’ve watched a tremendous 60-minute talk online, how to share this with your team effectively? We’re all busy, so sending a video link to your colleagues turns down to say, “you’ll ALL need to spend 60 mins of your time to watch this as it’s a must-see”. Like blog posts, sometimes they’re pretty long and need more attention.
An actionable tip is to set a 15-minute weekly meeting where participants can summarize a blog post they read or a conference they watched and highlight the key findings and what they’ve learned (you can adapt the frequency and duration, like a 1-hour monthly meeting). People returning from a multi-day conference often organize an internal meeting with their team to share feedback and summarize their favored talks. So, don’t push content or links; take it as an exercise to summarize your thoughts and communicate them with your team.
Set a culture to support knowledge-sharing
Our key message is that knowledge sharing can’t happen if engineers are not committed to sharing with others.
Capitalization is vital in this process. As a tech leader, you should make the most of each opportunity to upskill developers, bring technical interactions and discussion, and ensure continuous knowledge streams connect each developer in your team. As you noticed, we encourage regular
collective synchronous meetings, mainly when you deal with complex topics that involve the whole team. But don’t make it
yet another meeting: create a place where everyone gets value.
