Along with the growth of the code base, the entry threshold that newcomers need to overcome to fully immerse themselves in the project grows. There’s also the situation where experienced employees don’t know how some of the mechanisms in an existing system work. With the natural process of personnel turnover, it also happens that experts leave the company, while newcomers have not yet had time to gain critical knowledge. In this case, the old team will “die” without the exchange of knowledge: the newcomers will not be able to understand the old code and will not know why a particular architectural solution was adopted, and this will lead to a rewrite of the project.

To avoid this situation, it is necessary at the level of the company in general and the team in particular to organize knowledge exchange and constantly maintain this culture. Below I will give the different ways of sharing and subjectively evaluate their effectiveness and complexity of implementation.

Creating wiki pages

You can create a knowledge base in an enterprise Wiki/Confluence. The disadvantage of this method is related to keeping the information up-to-date. As a rule, the most useful information about the project are UML-charts and the most basic concepts.

List of resources, selections

The method is similar to the previous one, but it is more focused on self-study. Allows you to find the most interesting topics for study, as well as understand with whom these topics can be discussed. It is desirable to write a mini review for each item in a selection, or at least a couple of words, it will help to understand new information better.

Chats on a narrow subject

A knowledge base on a process or project can also be a chat room. The information in it is less structured, but as a rule, you can always see a list of photos, links and files already sent, and on the basis of them go deeper into the subject or find an expert. The main thing is not to allow conversations outside the topic of the chat. I recommend to use fastened messages not to lose the important information.

Writing articles

As a rule, material search and research while writing an article gives a strong impulse to the author’s outlook; the experience you get may be useful and relevant to your colleagues. For example, the topic for an article may be some “pain” in the project or a description of an experience gained. To prevent the writing process from dragging on indefinitely, it is better to come up with some deadlines or create them artificially. If the articles are published on external sites and strengthen the HR-brand of the company, then it is worth to consider options of encouraging the authors to maintain motivation.

Incident databases

The results of incident handling can be systematized in a Wiki and used to train newbies on the experience they have already gained, while for senior employees it will be useful to revise this knowledge to identify key information and take systematic measures

Ways based on live communication

You can’t force knowledge sharing, but you can create all the conditions for people to want to share their experiences. Also, live communication protects against burnout and promotes team building.
Playgrounds to run through reports

Even experienced speakers need to read a report several times and gather feedback to improve the material, and for listeners, this can provide new insights and encouragement to speak. Motivation for outside speaking engagements can be an opportunity to build and develop a personal brand.

Creating communities and guilds for different technologies

Creating engineering communities within a company has become a fairly popular way to gain experience and share knowledge recently. Such communities are highly dependent on leaders who are ready to develop an area of interest on their own enthusiasm, and as a rule, at the start need additional support from the management.

Architectural Committees

To make complex and long-lasting engineering decisions, you can assemble so-called “architectural committees. At these meetings the standards to be followed by the whole company are worked out (as a rule, these standards will be obligatory only for new projects, and the old ones are brought in accordance with the adopted standards as needed), or the architecture of new services is discussed. It is recommended to allow anyone to speak at the architecture committee, but to leave the right to vote only to experts in their field (democracy games do not work when making important technical decisions).