Effective Knowledge Sharing
Overview
This blog focuses on the “Knowledge Sharing” chapter of the Software Engineering at Google book. Knowledge comes in many forms and is a crucial asset within a software engineering organization. In this article, we explore the challenges of learning and knowledge sharing and effective strategies for fostering a culture of collaboration and communication. Key topics include the phenomena of Information Islands, Psychological Safety, and Information Duplication, which hinder knowledge sharing. We also discuss various methods for scaling knowledge, such as group chats, mailing lists, and office hours, along with the importance of clear documentation and code review practices. We will be taking these practices and connecting them to our team’s current situation with execexam, as well as how this chapter builds on the concepts we discussed last week.
Summary
Though it is not a tangible item, knowledge is the most valuable asset of a software engineering organization. This chapter discusses challenges that can arise in learning, which make sharing knowledge difficult, ways to grow your knowledge, and how an individual or organization’s knowledge can best be shared and made available as the valuable resource it can be.
Such learning challenges mainly arise due to a need for a system for communication between individuals and different teams assigned to various projects. Some also arise from a fear of being wrong or looking under-qualified in front of others. This chapter also discussed the importance of having a philosophy and shared what that looks like for those employed by Google.
The most efficient way to grow knowledge is to ask questions, something that should not come across as intimidating, but instead helpful. Finally, the various ways to share knowledge as an individual were discussed, with an emphasis on proper documentation and code review practices. Information Islands occur when information is only available from one person or group. Though we are split into groups for our respective projects for adding features to Psychological Safety, or a lack thereof, stems from people being afraid to ask questions because they feel inadequate or fear the judgment of others. We can prevent this by encouraging each other and being kind and patient when helping out a colleague. Also, we can keep in mind a point made in the SE book, that “the more you know, the more you know you don’t know.” That is to say, knowing more doesn’t make you an all-powerful genius who no longer has a need to learn, so chances are, your less experienced colleagues have plenty they can teach you. Information Fragmentation is when each island, or team, has an incomplete section of the larger whole. In our case, the larger whole would be execexam and the incomplete sections would be our respective features. Similar to the Information Islands section above, “Information Fragmentation” can be avoided by using the start of our Thursday sessions to share updates and get everyone present on the same page. Information Duplication is when each island, or team, has reinvented their own way of doing something. Similar to both the Information Islands and Information Fragmentation sections that were previously mentioned, “Information Duplication” can be avoided through sharing knowledge as a group and giving updates at the start of our Thursday sessions. Information Skew is when each island, or team, has their own way of doing something and these ways might conflict with one another. For us, running into this issue would be a huge problem as it would cause us to experience major setbacks as we decide which method to go with and so on. We saw this a bit with our first Thursday meeting. A great way to avoid this is to break our group into teams and give each team a different task to complete, like we have done using Pallas’s spreadsheet. Also, a great way to avoid this is to use the beginning of our Thursday meetings as a way to update each other on what works, what doesn’t and any progress. Using discord between meetings can help with this as well. Single Point of Failure, or SPOF, happens when one person is the source of expertise for a given area. This is closely related to the “Bus Factor” from How to Work Well on Teams as it also has the notion of dire consequences where something can go quite wrong with only one person in the know. One way we have taken steps toward avoiding this issue are having different levels of experience on each team. This approach ensures that at least one other person will learn more in a given area and helps take steps toward avoiding the consequences of the “Bus Factor.” Another way we can avoid this is once again by using the start of our Thursday meetings as a way to share information with one another. All-or-nothing Expertise ties in with SPOF as it occurs when a team is composed of the “know-it-alls” and the “novices.” This creates an environment where the novices don’t really learn and the know-it-alls do all the work. This is not only bad for the sharing of knowledge, but it also creates a divided team and environment. We can avoid this by having our teams be mixes of experience and expertise. Also, we can set expectations for the more experienced members to be a little more patient and willing to explain to those with less experience. Parroting is when someone mimics without understanding. In other words, someone maybe copies code without understanding it. We can avoid this by asking someone to explain when we don’t understand as we should all know how the code for any of our tools works. Also, this can be avoided by having the mix of expertise on each team with the more experienced member(s) being willing to explain the code. Haunting Graveyards occur when people are afraid that they will touch the code and break something. This can be avoided by not being afraid to try and acknowledging that it is better for one of us to break the code than for someone in the department to use our software and break it after we’ve shipped a feature. Discuss what you think our philosophy should look like Google makes specific points with phrases and actions to avoid. They mention feigned surprise, correcting colleagues, or “well-actually” and “backseat driving”, and saying how easy certain tasks are or “my grandma could do that”. These actions and/or phrases can all have adverse effects on psychological safety in the workplace and make newcomers feel severely under-qualified. Leveraging community-based learning will be a key aspect of achieving success in our software team. Google uses the following three approaches to enable knowledge seekers to get help from the broader community. Group Chats are a great way to receive quick help or feedback since you can ask a question to many people at once, and anyone can jump in. These chats can be centered around certain topics or teams, enabling“experts” to answer questions swiftly. However, group chats are often unstructured, making it difficult to locate meaningful information later. Mailing lists provide knowledge seekers the ability to ask questions to wide audiences in a structured manner and have the advantage of being archived for future reference. Mailing lists provide a space for complex questions but are not suitable for back-and-forth communication. Furthermore, information from archived lists may be outdated, so it is important to update the list if outdated information is found. Question and answer platforms offer a unique space to share specific and evolving questions with “exact” answers. Google uses these platforms to discuss work-in-progress code segments while getting updated, helpful information. The Q&A platform structure makes it helpful for current and future references. Discuss what tools we currently have in place that relate to Google’s Group Chat/Mailing List/Q&A Platform Our discord widely is used in a similar fashion to that of a Google group chat, where we are able to communicate with back and forth quickly with light structure. We then have specified channels that handle topics and teams that can be seen as our version of a mailing list. We also use these channels as an avenue for Q&A type sharing due to the nature of sharing code blocks, terminal outputs and specified questions. Teaching and learning go beyond being an “expert” or “novice” –– everyone has varying levels of knowledge in various areas. To be a successful software team we need to share our “expertise” in a way that fosters productive learning. Here are some of the ways Google creates environments for productive knowledge sharing. Attending scheduled meetings with experts can be a productive way to take advantage of someone’s expertise to tackle complex or ambiguous problems. In our course, we can leverage the expertise of our various technical leaders, as well as Professor Kapfhammer during his office hours. Class sessions offer groups an opportunity to explore complex concepts together through hands-on activities and resource-intensive material. Class material can also be documented to be scaled and reused for future use. In what ways does our course use class sessions in a similar way to Google? In our course, our colleagues take turns being the “expert” on a given concept(s). We utilize our Monday session exploring professional concepts and our Wednesday sessions exploring a technical concept. Written knowledge is crucial in any form of knowledge sharing because clear, well-written documentation minimizes future confusion and improves organizational efficiency. When discussing documentation it is important to consider these key points: Code itself is a form of knowledge, therefore writing well-documented code and a system of code reviewing is extremely beneficial to a software team’s ability to efficiently produce bug fixes and new features. Doing the work upfront will help not only our team but the teams that will follow us. Establishing a culture of productive habits will be crucial to the success of our team this semester. Alongside Chompers’ Philosophy, our team needs to be built on fundamental concepts discussed in SE4: respecting others, showing kindness, and recognizing our colleagues’ great contributions to the team. Additionally, Google has an extensive Readability Process for code readability, as found in “Knowledge Sharing”. Discuss in your group: Do we have a process of reviewing readability like at Google? What is our process? Should we have this process? Why? Yes we should have a code review process! As Nina Chen and Mark Barolak explain in “Knowledge Sharing” that “code is read far more than it is written…” which means having a process to review readability is crucial to ensure our code is easily understood. Secondly, reviewing each other’s code exposes us to new knowledge from new areas of our team. Our process of having PRs on our tools being reviewed by two fellow students and a technical leader is one example of our code review process.Challenges to Learning
Information Islands
execexam, this can be easily remedied. To avoid “Information Islands” we can continue to utilize the start of our Thursday meetings to provide updates about what we are up to. Also, we can utilize discord to share briefer updates or issues that may need a bit more help to solve. This also relates to the “Bus factor” we discussed in How to Work Well on Teams. By sharing knowledge at the start of our Thursday meetings, we can also alleviate this issue.Psychological Safety
Information Fragmentation
Information Duplication
Information Skew
Single Point of Failure (SPOF)
All-or-nothing Expertise
Parroting
Haunted Graveyards
Chomper’s Philosophy
Click to Expand for the Answer
Knowledge Sharing
Scale Your Question
Group Chats
Mailing Lists
Q&A Platforms
Click to Expand for the Answer
Scale Your Knowledge
Office Hours
Class Sessions
Click to Expand for the Answer
Documentation
Code
Scale Our Knowledge
Click to Expand for the Answer
Reflection
It is important to be aware of challenges that may impact the ability for people to learn in this environment. Also, our philosophy should remain at the core of our group, representing our values. Finally, we need to keep in mind the ways in which we can best scale our knowledge both as individuals and a group.