Ask HN: Does anyone have a system for preventing tribal knowledge? | Hacker News Reader

Ask HN: Does anyone have a system for preventing tribal knowledge?

10 pointsalexfromapex13 comments

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.

This is like automated testing. Perceived value is high -- so why is it so rare?

Very time consuming so probably lot of companies will skip on this to deliver features faster.

Having robust documentation that contains all the knowledge so a completely new team without any project knowledge can easily deploy/support the project can be a big task, especially for large projects.

Even with really good documentation, there will always be required some handover and initial training from the maker team in my experience, it is almost impossible to avoid this.

I guess during sprint planning, if this requirement is being included and the estimates from developers start doubling suddenly the product team might compromise in order to move faster.

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.

Only works if its done happily and willingly and most of all consistently. Wikis are often passion projects and it is rare for managers to consistently push their utility and it is very difficult for them to get usable metrics from them in my opinion.

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"

I recently worked for a telecom and they had an unspoken policy of cycling out techs and engineers with regularity. I cannot count the horror stories where a handful of semirandom firings caused a system that hundreds of people relied on to meet productivity quotas stopped functioning within weeks due to the semirandom person being fired being the person that ran the system.

They spent millions of dollars a year constantly rolling out replacements for these systems that were always without fail worse than the ones we had because the vendors they threw this money at weren't building specific use applications for a single business function and it seemed like every new app had a wiki function, a chat function, and a smartphone app when all we needed was a way to look up a coworker's permissions or update a ticket.

Tribal knowledge cannot be evenly distributed in a business system because not everyone in the business system needs to know it. The mail person does not need to know the CEO's advertising strategy. But in an ideal meritocratic system the CEO would know the mail person's contributions to the system and wouldn't replace them with (for instance, a series of air tubes) if that mail person was considered to bring warmth and happiness to the people they interacted with, providing value far in excess of their letter-distribution capacity.

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.

Reply on news.ycombinator.com