Software evolves quickly.
Whether it’s being frantically written by a solo entrepreneur at a newly-founded startup or a team of well-funded engineers at a Fortune 500 company, the ability to execute an idea quickly is one of the single most important skills in software development today.
Why companies are shifting to Q&A as the new format for knowledge management. Download now (pdf)
When you’re moving fast, it’s easy for things to break, or for important elements to fall through the cracks. One of the biggest challenges is the profound lack of documentation that happens when you’re moving a million miles an hour. After all, who has time to write everything down when you’re charging at full-speed towards that Series A or working overtime to beat the competition to market?
Enter the Knowledge Silo
Unfortunately, as projects grow, so too do the teams that build them. If you’ve ever experienced the rapid expansion of any project team, then the concept of knowledge silos should be all too familiar. What was once common knowledge amongst a small handful of developers gradually becomes the privileged information of a chosen few. Knowledge silos are part of the natural evolution of project growth. As a project grows beyond the scope of one or two key team members, the information that has been kept almost solely in their own heads needs to be passed on too. Unfortunately, this rarely happens in a reliable manner. Out of convenience rather than any animosity, knowledge silos typically start as a crutch that new team members lean on after basic onboarding; they learn what they need to be generally effective, and then shoulder tap on subject matter experts within the team for the more proprietary subjects. As the team grows and becomes more dispersed, this oral tradition often evolves to written documentation. Getting this information out of heads and written down is the only way to enable teams to grow. It also unburdens siloed engineers whose own productivity might be suffering because they’re spending more time answering questions than anything else.
Legends of the Hidden Knowledge
Effective and satisfied software engineers have a sense of ownership over their work. The ability to take the reins on a feature and truly own its design and development can result in a deep sense of job satisfaction, but the risk of ownership is isolation. This is information that you explicitly know that you need to document. When features are developed in a bubble, organizations begin to lose sight of what is known. For example, a common knowledge silo in many organizations is the customer billing process. Normally, the details of this process are known to only a handful of people, but most people know who owns that silo. We may not know what knowledge needs to be documented, but we do know that there is knowledge that needs to be documented. But there’s another kind of knowledge, hidden from the people who know it—tacit knowledge. Rather than information that is known by only a small set of people, tacit knowledge is information that isn’t even acknowledged by the organization; it’s information that may be known by a small set of people, but it isn’t even tracked by the rest of the organization outside of that group. This information is often nuanced, such as the deployment process of a seldom-used microservice, or the non-standard configuration values in the primary application.
The Lottery Factor
While every organization is bound to have a few sets of knowledge silos and hidden knowledge, identifying whether or not those silos are becoming bottlenecks in productivity is a key first step towards understanding how best to solve the problem. If you are not sure how to determine whether or not a knowledge silo is a bottleneck, consider the lottery factor as a litmus test.. Imagine an employee wins the lottery, walks into work the next day, and quits without notice. They leave for their private island on a jet and don’t communicate beyond that or engage in any off-boarding. It’s a useful exercise when determining the inherent risk that a knowledge silo might pose to an organization. While the lottery factor is an extreme case, knowledge silos can have a regularly negative effect on productivity when those key team members go on vacation or take sick leave. If your entire organization’s productivity suffers because a single employee gets a cold, that’s a pretty good sign that it’s time to start distributing some knowledge.
It’s Not All About Productivity
Like any good relationship, communication is key, and while early-stage projects often communicate need-to-know information quickly and informally, this tactic of knowledge-sharing isn’t sustainable. At a certain point, it becomes impossible for any one person to maintain the entire knowledge base of a single project in their head, which means that documentation becomes the key to sustainable growth and effective planning. It is impossible to work effectively in the long term without clear and accurate documentation in place. Without it, there will be a change that goes against the undocumented best practices of a project, or a tweak to a configuration value that was originally created to accommodate a nuance in the codebase. Perhaps more importantly, your team must know that this documentation exists and how to gain access to it. In the end, everyone should be able to easily find the answer to “why” something works the way it does.
See how Stack Overflow for Teams can transform collaboration within your organization. Learn more