Over the years I’ve done projects for many companies and one of the most common recurring issues is what I call “tribal knowledge”. This basically refers to the “core” technical knowledge and intellectual property which makes up a company’s product, but for the most part, exists only in the minds of those who create and maintain the product because nobody bothered to document it. In case it isn’t obvious, let me point out that this is a serious problem for many reasons, as I’ll discuss in this article. The good news is that tribal knowledge can be avoided or overcome through the use of good technical documentation and a good technical writer.
Before I delve into the solutions however, let’s talk about the problems and their causes, noting that tribal knowledge poses a serious threat to the very business model around which a company is built.
When information only exists in the minds of the programmers, designers, and other technical employees who design, implement, and maintain a product, the loss of any one individual could have serious consequences for the company.
Take for example a build engineer, who, over time has come to own and maintain a complex set of build scripts but has never documented how they work. Should that person suddenly leave the company for one reason or another without transferring their knowledge, it will be very difficult and time consuming to maintain, enhance, and fix those build scripts. The problem becomes orders of magnitude worse when the same scenario happens to many individuals at the same time (e.g. due to mass layoffs).
The main cause for tribal knowledge simply comes down to a lack of internal documentation. Often is the case that technical documentation is seen as overhead, with its creation and maintenance viewed as an expense that provides questionable value with a return on investment that is difficult to measure.
To some degree you can’t argue with this logic, but it’s not until you start to consider the consequences of tribal knowledge that you realize that what may be questionable to create now, could be a life saver later.
As an analogy you could almost look at the investment in internal technical documentation in a similar manner to that of buying insurance. Year and year out we buy all sorts of coverage from car insurance, house insurance, business insurance etc. knowing full well that the probability of using it is small, but the consequences of not having it when we need it could be catastrophic.
So while the solution is to invest in internal documentation, the good news is that you don’t have to go overboard. If your company is suffering from tribal knowledge, below are a few ideas on how to get started.
The first order of business is to raise awareness, especially with managers and other decision makers responsible for budgetary planning. They need to be made fully aware of where the current bulk of knowledge exists, and the importance of getting it recorded somewhere.
With that done, the next order of business is to allocate time for everyone to record their knowledge. This could be as simple as a creating a wiki where everyone is required to dump their knowledge, to something more complex such as formal design documents. The important point here is that documentation is never “done”; everyone needs to be constantly recording their knowledge and updating the content that they’ve created.
As part of this, it’s also important that everyone knows where the documentation lives. This may seem trivial, but I’ve seen many companies where documents live in all different areas of the network. Often times this occurs when the company switches to a new information management system, but keeps the old one around. In larger companies this tends to be bigger problem as such switches tend to re‑occur every few years. So be sure to factor some maintenance time in for migration to new information management systems, and removal of information from old, outdated systems.
Another idea worth allocating time to is a documentation audit. When done on a regular basis (e.g. yearly), an audit can be used to assess the currently recorded information to see if it’s up to date, and if new or potentially new employees could take that information and get up to speed quickly with it. Part of this goes with the old adage that I’ve said many times before, that incorrect information is often worse than no information. So remember that internal documentation, like product development, is a never ending and evolving process.
Finally, if you’re lucky enough to have the budget, a technical writer is the best investment here. Since many companies don’t have the budget for full‑time staff, a contract writer such as Essential Instructions, can be utilized on regular basis to capture tribal knowledge, organize it, and maintain a quality set of internal technical documentation that will ensure the business can survive threats to it staff members.