This is the fourth article in a series where we cover the book Software Engineering at Google by Titus Winters, Tom Manshreck, and Hyrum Wright. 📕 We will go over various aspects of software engineering as a process, including the importance of communication, iteration and continuous learning, well-thought-out documentation, robust testing, and many more.
Knowledge is in some ways the most important, though intangible, capital of a software engineering organization, and sharing that knowledge is crucial for making an organization resilient and redundant in the face of change. This is the topic we discuss today!
When we consider all of the information we obtain and share as software engineers, it can be categorized as one of the following. 📝
Tribal knowledge. This type of information is informal or undocumented. It's often communicated directly from individual to individual. Ultimately, it's known to a selected group of people and unknown outside of it. You can think of it as institutional memory, spread across members of that institution.
Formalized knowledge. This type of information is often structured, codified, and documented. Because of this, it can be exposed to anyone who is willing to consume it (and has permission to do so). Most likely all of your documentation falls under this umbrella.
There are different implications to using one or the other type of information, across aspects such as up-front costs, maintenance costs, ease of sharing, discoverability, and searchability. Tribal knowledge is often vilified due to having an inherently low bus factor.
The "bus factor" is the minimum number of team members that have to suddenly disappear from a project before the project stalls due to lack of knowledgeable or competent personnel.
The book, however, outlines that tribal and written knowledge complement each other. Even a perfectly expert team with perfect documentation needs to communicate with one another, coordinate with other teams, and adapt their strategies over time.
No single knowledge-sharing approach is the correct solution for all types of learning and the particulars of a good mix will likely vary based on your organization. It's key to remember that institutional knowledge evolves over time, just like your product or your codebase. The knowledge-sharing methods that work best for your organization will likely change as it grows. 🌳
Learning requires the right environment
All learning and knowledge sharing requires communication, so all of the communication principles we outlined in part three do apply here. 📢
There's one aspect that's critical to promoting a learning environment, and it is creating psychological safety. The book emphasizes, that to learn you must first acknowledge that there are things you don't understand. We should welcome such honesty rather than punish it.
An enormous part of learning is being able to try things and feeling safe to fail. In a healthy environment, people feel comfortable asking questions, being wrong, and learning new things.
Everyone can be a teacher
Teaching is not limited to experts nor is expertise a binary state in which you are either a novice or an expert. The book mentions that expertise is a multidimensional vector of what you know: everyone has varying levels of expertise across different areas. Teaching also is a great way to force yourself to understand a given topic even deeper and solidify your own knowledge. 💡
One interesting thing I heard in the past is that experts in the field might not be the best at explaining concepts from that field, especially the more rudimentary ones. They've probably learned the basics a very long time ago. Since then, they likely acquired a lot of knowledge that relies on understanding these fundamental concepts. For that reason, basic information becomes transparent to them, which in turn might make it hard to explain or empathize with people who are struggling with understanding it right now.
Sometimes, a person who has just learned a particular concept might be a better teacher than an expert, who has long forgotten how it felt to learn this years ago.
A great first step you might want to get the knowledge-sharing snowball going, is when you find an answer to a question you asked, don't just get back to your work. You never know when someone will need the same information in the future, so it's best practice to post the answer back. ✍
Knowledge sharing done right
As with anything, practice makes perfect. Theoretical divagations aside, here are four actionable steps you can take to create or foster a learning and knowledge-sharing environment.
Knowledge sharing starts with yourself. It is important to recognize that you always have something to learn. Make this a priority for your own career. Always be asking questions.
Go one level deeper. Learning is not just about understanding new things. It also includes developing an understanding of the decisions behind the design and implementation of existing things. Understanding concepts one level deeper than required will make you a better teacher.
Optimize for scalability. Getting one-to-one help is high bandwidth but necessarily limited in scale. As a learner, it can be difficult to remember every detail. Do your future self a favor when you learn something from a one-to-one discussion, write it down, and share.
Reward and profit. Make it easy for people to get the help they need from both human experts and documented references. At a systemic level, encourage and reward those who take time to teach and broaden their expertise beyond just themselves, their team, or their organization.
Conclusion
That's a wrap. Investments into easier knowledge sharing reap manyfold dividends over the life of a company. Here's a short summary of things we went through:
tribal knowledge and formalized knowledge complement each other
knowledge-sharing approach depends on a company and evolves over time
learning requires psychological safety
everyone has varying levels of expertise across different areas
teaching is a great way to learn more thoroughly
Next, we will go much closer to the code and discuss code style and code review. See you! 👋
If you liked the article or you have a question, feel free to reach out to me on Twitter‚ or add a comment below!
Further reading and references
