How to establish an exchange of knowledge in a company so that it doesn’t hurt (post exchange of experience)

The average IT company has requirements, a history of task trackers, source codes (possibly even with comments in the code), instructions for typical, important and complex cases on the prod, description of business processes (from onboarding to “how to go on vacation”) , contacts, access keys, lists of people and projects, description of areas of responsibility – and a bunch of other knowledge that we probably forgot about and which can be stored in the most amazing places.

Knowledge = / = documentation. It cannot be explained, it must be remembered

How to make sure that those who needed to learn something from this, understood where and how to find it, and everyone who needed to be aware of certain things and agreements could instantly and accurately learn about changes in them.

In the final episode of the Timlid Calls podcast, the guys from Skyeng talked about knowledge management with Igor may-cat Tsupko, a person from the KnowledgeConf program committee and “director of the unknown” in Flanta.

Full recording is available as YouTube video, and below we have collected some interesting tips and links to useful materials that were mentioned in the audio or expand the information from it. It will be great if you also share the hacks and rakes of your team in the comments.

First hack: you no longer need to know which system to look for

“I took our sources of knowledge and did a general search on them: such a single window with a filtering system to reduce the search area. Yes, while you still need to monitor its quality, replenish the knowledge base, fight duplication and erroneous information.

One hanger to find that’s it

But now about 60% of Flant engineers use this search at least 1-2 times a day – and usually find answers in the first or second position. And in the form of proof of concept lies the indexing of Google documents: all the docks, folders, van drives, and so on – it’s also easily fit into an internal search. ”

Second hack: how not to miss the critical in the heap of chats

“If you work in a distributed team, then for sure the noticeable part of your day goes to Slack – and in which case you’re used to doing something like this:“ @myteam, help / watch / enter the right one … ”. But there is a problem of an abundance of information – and a separate mention can be skipped among other messages.

We at Skyeng are helped by a bot through which you can write a message and tag any number of people or groups. We use it in cases where it is really important that people read or respond: it will poke endlessly until you click the “I read” button – it will not work to skip or ignore it. ”

Backfill question: what to do with the documentation?

“A lot of knowledge comes from techies, but not everyone knows how to describe it well.
After all, you do not have any compiler or linter that would say whether you are doing the right thing or not – and often at the output we have incomprehensible, poorly designed and incomplete text. Of course, it is not necessary to do normally, because someone came and said “it is necessary” – you yourself are doing well: after a month or two, you will read and understand. And the other person, opening the dock, will not immediately close it forever, realizing that it is none.

Part of the podcast on the question “How many people do you need to write good documentation or make a normal demo”

But the question remains: how much time should be allocated for this and how to do it in a quality manner?
And if there is an honest answer: if people from the business are not involved, and if they empirically do not feel the return on good documentation, there is a risk that the attempts will give small returns. This is more a story about cultural change.

And the rest, experience and mentoring will save you. Here analogs of pair programming, tracking of progress and code review may come up – showing the best practices, poking errors and nudination in the end. ”

Bonus: “Come on, I’ll tell them so, they will understand”

The question “how much time to spend on it and at what level to do” is important not only in the framework of the documentation, but in general for the transfer of any knowledge. The demo is also a great example of sharing information. But there are nuances: for example, how to make them minimally take time.

Knowledge sharing channel among development: internal reports, useful books, articles, etc. Structured squeeze is also stored in Notion.

Partly these problems help solve the practice of internal reports. Once a week, it takes 40-60 minutes at a busy time – and the guys make a video report for colleagues from different projects. The front-end team of the key product – Vimbox – talked about its UI kit, which can be themed for any other project. The marketing development team is about a library for tracing and logging requests, which immediately interested several more projects. The team of the project “Mathematics” shared the experience of the transition from REST API to GraphQL. The group lesson team is thinking of telling how it first migrated to PHP 7.4. Etc.

The list has been maintained since May 2018 and has over 120 entries

All meetings are made through the corporate Google Meet, are recorded and provided within a day in a folder on a shared Google drive, and links to records are duplicated in the same Slack. That is, you can don’t come if you have an emergency, and then look at 1.5 speeds — usually the report itself lasts up to 20 minutes, and the discussion how it will turn out. But we don’t go beyond the hour)

p.s. And what worked and didn’t work for you?

Useful links: