Do you mean people not handing down tribal knowledge? Or preventing something from becoming tribal knowledge to begin with?

If the goal is to avoid something becoming tribal knowledge, then don't consider a project complete until it has been documented and a completely different team has deployed and supported the project without any need to talk to the engineers/architects/developers that created the project. There will always be feedback loops to improve a project, but if a completely unrelated team can't deploy and support something, then you have tribal knowledge that has not been communicated in documentation, including self documenting code and/or videos. There is much more to this of course and hopefully others here will add more tips.

Regular discussion groups across the various divisions in your company. What's a division? I'm not speaking about corporate divisions, but any separated groups. You really want to do this with groups that have overlapping responsibilities (over the same thing or the same kind of thing). I used to have the PMs meet every other Friday to get a brief 5-minute spiel from me about things that had been decided above any of us, and then the rest was open discussion. Started off as a whining session, but later on they started asking and answering each others questions and setting up knowledge exchange meetings and efforts ("Can I borrow your SME for a few weeks to teach my people how to do this properly?").

Readme's that actually talk about the purpose of the service and where it fits into the whole and helps the developer form system level understanding, runbooks that have step by step guides and reasons for alerts and errors, design discussions, design documents, sometimes pair programming on harder areas, appropriate tests, appropriate comments, real code reviews where the reviewer seeks to understand the code and the change, idiosyncrasies written in the readme, purposefully deconstructing silos of information (spread responsibility/knowledge) and removing single points of failure by having less experienced folks get trained up and begin taking on responsibilities that were siloed and updating onboarding documentation while doing so, group code reviews on tricky changes, communicate issues and solutions to the team at large, team alert reviews, team error reviews, graphs and metrics have descriptions in plain words describing customer/user impact, and probably some other things we do.

Here's a kitchen sink reply: https://news.ycombinator.com/item?id=28422944

Many of them pertain to communication, leveraging your presence, especially the one titled "If I disappear, what will happen". The way I put it is to put yourself out of your current job and to be able to die without impacting the team beyond nostalgia.

We have long conversations about product, distribution, sales, marketing. We update our knowledge base regularly.

When the CTO and co-founder of a company you have joined quits a year and a half alter and the CEO is in another country, you get obsessed over making sure the company survives (https://news.ycombinator.com/item?id=26182988)

Use a wiki for a knowledge base. Cheer people adding info to the wiki, even incomplete info. Require no approval from anyone to update. Allow the entire company to update the wiki, with revision history. Trust the employees to correct wrong stuff as they find it.

Another classic stolen and then changed original people’s value. What represented the knowledge of ALL the tribe now means the knowledge of only a few.

In any case this is what the OP refers to:

https://en.wikipedia.org/wiki/Tribal_knowledge

Tribal knowledge is jargon terminology used to describe information that is known within a group of people but unknown outside of it. A tribe, in this sense, is a group of people that share such a common knowledge. From a corporate perspective, Tribal Knowledge or know-how is the collective wisdom of the organization. It is the sum of all the knowledge and capabilities of all the people"

Build a culture where someone who is getting really strong in one aspect of the business/code/ops will start pairing with someone else to share that strength. Build a reward system where people are incentivized not for being the expert, but for bringing up expertise across the team.

I vaguely remember one of my engineering professors mentioned mandatory job rotation within some defense contractors as a way to prevent that. The trade-off is that no one becomes an absolutely specialist in an area. His field was radar-related work.

I think some kind of tribal knowledge is extremely difficult to document and share.

undefined