Tribal Knowledge: The Unwritten Know-How That Keeps Organisations Running

Every workplace runs partly on things nobody wrote down. One machine has to be warmed up for ten minutes before it holds tolerance. One customer always rejects an invoice unless a particular reference number is on the first line. The night shift knows which alarm can be ignored and which means trouble. Nobody remembers why a configuration setting is what it is, but changing it breaks everything. This kind of knowledge is often called tribal knowledge: know-how shared within a group but not recorded in any form an outsider could easily find or use.

In a business setting, the term usually means knowledge that an organisation depends on but has not adequately documented. It survives because people pass it on to one another through mentoring, apprenticeship, working side by side and long service. That makes it powerful, because it is often the knowledge that turns a written procedure into good work. It also makes it fragile, because it can walk out of the door when the people who hold it leave.

This article explains what tribal knowledge is and where the term comes from, how it relates to tacit knowledge and other ideas in management research, why it forms, what research says about how knowledge moves within organisations, the risks it creates, the methods organisations use to capture and share it, and the criticisms and limits of those efforts.

What the term means

A working definition

Wikipedia's article on the subject gives a two-level definition. In the broadest sense, tribal knowledge is any knowledge known within an in-group but unknown outside it. In the corporate sense, it can mean the collective know-how of an organisation. In management science it usually has a narrower meaning: a kind of institutional memory that is essential to how the organisation works, inadequately documented, and kept alive mainly through mentoring, apprenticeship, on-the-job training and staff continuity.

Several features follow from that definition:

It is unwritten, or written only in scattered, informal places such as personal notebooks, chat messages or comments in code.
It is held by a few people, often those with long service or a specialised role.
It is often essential, the difference between doing a job and doing it well, or between a process that works and one that fails.
It may be right or wrong. Wikipedia's article notes that tribal knowledge may be accurate or entirely mistaken. A workaround that once solved a real problem may persist long after the problem has gone. A rule of thumb may never have been true.
It can be converted. Unlike some forms of personal skill, much tribal knowledge can, with effort, be turned into documented organisational property.

Where the name comes from

The phrase draws an analogy with human groups studied in cultural anthropology, in which knowledge, customs and skills pass from one generation to the next by example and word of mouth rather than in writing. Wikipedia's article notes that some regard the expression as jargon, but that it remains the most widely established label for the idea in business use.

Related terms overlap with it, and it helps to keep them apart:

Term	Typical meaning	How it relates to tribal knowledge
Tacit knowledge	Knowledge that is hard or impossible to put into words, such as a skill or a feel for a situation	Much tribal knowledge is tacit, but some is perfectly explicit and simply unrecorded
Explicit knowledge	Knowledge that can be written down and transmitted in documents, data or code	The goal of many capture efforts is to make tribal knowledge explicit
Institutional or organisational memory	What an organisation as a whole "remembers" through records, systems and people	Tribal knowledge is the part of this memory that lives mainly in people
Know-how	Practical knowledge of how to do something	Tribal knowledge is often specialised, local know-how
Folklore	Shared stories and beliefs within a group	Workplace stories can carry real tribal knowledge, and sometimes myths

Tribal knowledge in the Six Sigma community

The term has a more pointed meaning in the quality-improvement movement. In the Six Sigma community, Wikipedia notes, "tribal knowledge" can refer to undocumented beliefs passed down within an organisation and assumed to be true without data or analysis to back them up. In this sense the phrase is partly a warning. Process improvement often starts by gathering what experienced workers believe about a process, and those beliefs are a rich source of factors to test. But they must be tested, because some will turn out to be wrong. Wikipedia's article describes tribal knowledge as a useful source of test factors in improvement work. The term carries both meanings at once: valuable experience, and unexamined assumption.

Roots in the study of knowledge

Polanyi: "we can know more than we can tell"

Much of the theory behind tribal knowledge goes back to the Hungarian-British chemist and philosopher Michael Polanyi. In The Tacit Dimension, first published in 1966, he summed up his position in a phrase that is still quoted: "we can know more than we can tell." A familiar illustration is that people can recognise a face among thousands without being able to say how. Polanyi argued that all knowledge rests on this personal, unspoken foundation.

Polanyi's idea is broader than tribal knowledge. Tacit knowledge in his sense may be impossible to write down fully at all. Tribal knowledge is a practical, organisational idea about knowledge that has not been written down, whether or not it could be. The two overlap heavily, which is why discussions of one so often turn to the other. Wikipedia's article notes that both form through personal stories, experience, mentorship and in-person training, and that both are hard to codify and transfer.

Nonaka and Takeuchi: converting knowledge

In 1995 Ikujiro Nonaka and Hirotaka Takeuchi published The Knowledge-Creating Company, which became one of the most influential books in the field. It developed a model, known by the initials SECI, of how organisations create knowledge by converting it between tacit and explicit forms:

Mode	From → To	What happens	Example
Socialisation	Tacit → tacit	People share experience directly, by working together and observing	An apprentice watches and copies a master
Externalisation	Tacit → explicit	People put experience into words, models or metaphors	An expert explains their method so it can be written down
Combination	Explicit → explicit	Documented knowledge is sorted, combined and spread	Manuals and databases are merged into a training course
Internalisation	Explicit → tacit	People absorb documented knowledge through practice until it becomes second nature	A trainee follows a procedure until it becomes instinctive

Nonaka's best-known illustration is the development of a home bread-making machine at Matsushita in the 1980s. The engineers could not get the machine to knead dough properly and could not work out what professional bakers did differently. A member of the team trained with a hotel's head baker, studying the kneading technique by watching and practising until the team could describe what the baker was doing differently. That description was then built into the machine's design. In SECI terms, the story runs from socialisation (learning by apprenticeship) through externalisation (finding words for the skill) to combination (turning it into engineering specifications).

The model has critics. One critical review in the Journal of Knowledge Management argued that Nonaka's use of "tacit knowledge" differs from Polanyi's original idea. Polanyi held that some knowledge can never be fully articulated, while the SECI model treats tacit knowledge as something that can be converted. The disagreement matters in practice. If some workplace knowledge cannot be fully put into words, then documentation alone can never replace the people who hold it.

Situated learning and communities of practice

A different line of research looked at how people learn at work. In 1991 the anthropologist Jean Lave and the educational theorist Etienne Wenger published Situated Learning: Legitimate Peripheral Participation. They drew on studies of how newcomers become competent in groups such as Yucatec midwives, Vai and Gola tailors, US Navy quartermasters, meat cutters and members of Alcoholics Anonymous. Newcomers begin on the edge of a group's work, doing simple but real tasks. As they take on more, they move toward full participation. On this view, learning is not mainly the transfer of facts from expert to novice. It is the gradual process of becoming a member of a "community of practice". Much of what is learned is the group's tribal knowledge: its ways of seeing problems, its shortcuts, its standards and its stories.

In the same year, John Seely Brown and Paul Duguid published "Organizational Learning and Communities-of-Practice" in the journal Organization Science. They argued that formal job descriptions and manuals describe work very differently from how it is actually done. Real work depends on improvisation, shared stories and informal learning within groups. Organisations that ignore this, they argued, misunderstand where their own competence lies.

The Xerox technicians

Brown and Duguid drew heavily on the work of Julian Orr, an anthropologist who studied photocopier repair technicians at Xerox. His book Talking About Machines: An Ethnography of a Modern Job was published by Cornell University Press in 1996. Orr found that technicians solved their hardest problems through talk. The official documentation assumed that faults could be diagnosed by following a decision tree. In practice, the difficult faults were the ones the documentation did not anticipate. Technicians told one another "war stories" about strange faults they had tracked down. Those stories were how knowledge of the machines' quirks spread through the group. Reviewers of the book describe the stories as the main way technicians kept up with the "developing subtleties" of machine behaviour.

Orr's study is one of the clearest documented examples of tribal knowledge in action. The knowledge was essential, constantly updated, shared within a group, and almost entirely outside the company's formal knowledge systems.

Why tribal knowledge forms

Tribal knowledge is not a sign of bad management in itself. It forms naturally, for several reasons.

Documentation lags practice. Processes, products and tools change constantly. Workers adapt faster than manuals are updated, and the adaptations live in their heads.

Some knowledge is hard to write down. The feel of a correctly torqued bolt, the sound of a healthy engine, or the judgement of when a customer is about to cancel resist written description. Polanyi's point applies here.

Writing takes time and has few rewards. In many workplaces, documenting work is not part of anyone's job description, is not measured, and competes with urgent tasks. People who are good at a job are often too busy doing it to write it down.

Knowledge is power. Holding knowledge others need can bring status, job security and influence. Few people hoard knowledge deliberately, but there is often little personal incentive to give it away.

Context is local. Much of what experienced workers know is specific to one site, machine, customer or team. It seems too particular to be worth recording, until the person who knows it is gone.

Trust and relationships matter. People share knowledge most readily with colleagues they know and trust. That naturally confines it to groups.

The "tribal knowledge paradox"

Leonard Bertain described what he called the "tribal knowledge paradox" in a 2010 book of that name. As summarised in Wikipedia's article, the paradox is a conflict inside organisations. Management rhetoric says that success depends on the knowledge and skill of workers. Yet the organisation's structures, processes and management behaviour often discourage the free flow of information that would spread that knowledge. Tight job definitions, internal competition, blame cultures and lack of time all push knowledge into private hands, even while leaders praise knowledge sharing.

Why it is hard to transfer: the research on "stickiness"

One of the most cited studies on moving knowledge within companies is Gabriel Szulanski's "Exploring internal stickiness: impediments to the transfer of best practice within the firm", published in the Strategic Management Journal in 1996. Szulanski studied 122 transfers of best practice, with 271 observations drawn from eight companies. He asked why a practice that worked well in one unit so often failed to spread to others in the same company.

The common assumption was that the main barrier was motivation: people resisting ideas "not invented here", or sources unwilling to help. Szulanski found that knowledge-related factors mattered most. Three stood out:

The recipient's lack of absorptive capacity. The receiving unit lacked the background knowledge to understand and use what it was being given.
Causal ambiguity. Nobody, including the source, fully understood why the practice worked. It was hard to say which details mattered and which did not.
An arduous relationship between source and recipient. Communication between the two was difficult or distant.

These findings fit tribal knowledge closely. A practice that depends on unwritten knowledge is causally ambiguous almost by definition: the people who do it well may not know which parts of their routine are essential. It needs a receiver who already knows enough to make sense of it. And it moves best through close relationships, which is how tribal knowledge spreads in the first place.

The risks: when knowledge walks out of the door

Turnover, retirement and the "bus factor"

The most obvious risk is losing people. When an experienced employee retires, resigns, is laid off or falls ill, any knowledge only they held goes with them. Wikipedia's article ties this directly to the "bus factor": the number of team members who would have to suddenly disappear (in the grim joke, by being hit by a bus) before a project could no longer continue. A bus factor of one means a single departure could halt the work.

Software development has measured this. A 2016 study by Guilherme Avelino, Leonardo Passos, Andre Hora and Marco Tulio Valente, presented at the International Conference on Program Comprehension, estimated the "truck factor" of 133 popular projects on GitHub. They defined it as the minimum number of developers who would have to leave before a project was incapacitated. They found that 65 percent of the projects had a truck factor of two or less. In surveys, developers from many of the projects broadly agreed that the people identified were the main authors. Open-source projects are not typical workplaces, but the study shows how concentrated essential knowledge can be even in large, public projects.

The ageing workforce

In Lost Knowledge: Confronting the Threat of an Aging Workforce (Oxford University Press, 2004), David W. DeLong warned that the retirement of the baby-boom generation would remove intellectual capital that many organisations depended on. He argued that the loss could seriously affect performance, especially in technology-intensive settings. His examples range from an expert NASA scientist and a veteran DuPont salesperson to senior executives. He proposed a framework for keeping vital knowledge both from retiring older workers and from mid-career employees who leave unexpectedly. Cornell's library summary notes that he cited organisations such as Sandia National Laboratories and the Tennessee Valley Authority among early adopters of knowledge retention.

The Saturn V and the F-1 engine

A widely repeated story says that NASA "lost the blueprints" for the Saturn V moon rocket. That is a myth. Writing in The Space Review in 2013, the space historian Dwayne Day explained that NASA had an active knowledge retention programme to preserve information about Saturn components, especially the F-1 and J-2 engines, and that the plans still existed. What was lost was different. As engineers retired or forgot how the engines were operated, NASA and its contractors lost knowledge about them. Manufacturing methods had also changed, so the engines could not simply be rebuilt as they had been in the 1960s. When engineers in the early 2010s began testing F-1 components, including a gas generator test at NASA's Marshall Space Flight Center, they were working with hardware whose original know-how had partly faded. That work supported a Dynetics-led team, which included the engine's original maker, Rocketdyne, under a study contract awarded in October 2012.

The story is a clear lesson. Drawings and specifications are explicit knowledge. They are necessary but not sufficient. The tacit and tribal knowledge of how parts were actually made, adjusted and tested, and why certain choices were made, is much harder to keep.

Other risks

Losing people is not the only problem tribal knowledge causes:

Errors and inconsistency. If each shift or site does a task its own way, quality varies and mistakes are harder to trace.
Slow onboarding. New employees take longer to become productive when essential knowledge has to be gathered by asking around.
Bottlenecks. A few experts become overloaded with questions and approvals because only they know how things work.
Wrong beliefs that persist. As the Six Sigma usage warns, unexamined tribal knowledge can preserve myths and outdated workarounds.
Barriers to change. Automation, new systems and process redesign often fail because they miss steps that existed only in people's heads.
Compliance gaps. In regulated industries, critical steps that are not documented may not meet audit or safety requirements.

Illustrative examples

The following examples are hypothetical, invented to show typical patterns. They do not describe real organisations.

A manufacturing plant. A press operator with 30 years' service knows that a particular die must be lubricated more often in humid weather, or parts crack. The rule is not in any work instruction. When he retires, scrap rates rise every summer until an engineer works out the cause, months later.

A software team. A deployment script includes a pause of 45 seconds that looks pointless. Only one developer remembers that an external service needs that time to finish an operation. A new team member "optimises" the pause away, and the next release corrupts data.

A hospital ward. Senior nurses know that one infusion pump model gives a misleading alarm in certain conditions, and they check it a particular way. The workaround is passed on informally to new staff. When agency nurses cover a busy weekend without that briefing, alarms are misread.

An accounts office. A long-serving clerk knows that a major customer's purchasing system rejects invoices unless the order number is entered in a particular format. When she is off sick for a month, payments from that customer stall.

Each example shows the same thing: the knowledge was real and valuable, but only a few people held it, so the organisation was more fragile than it looked.

How organisations capture and share tribal knowledge

There is no single fix. Approaches fall into two broad families, recognised in management research for decades.

Codification and personalisation

In a 1999 Harvard Business Review article, "What's Your Strategy for Managing Knowledge?", Morten Hansen, Nitin Nohria and Thomas Tierney described two strategies:

Codification: carefully capturing knowledge and storing it in databases and documents, where anyone can reuse it. They associated this with companies selling relatively standardised products and services. Their examples included consultancies such as Andersen Consulting and Ernst & Young.
Personalisation: keeping knowledge closely tied to the people who developed it and sharing it mainly through person-to-person contact. Technology is used chiefly to help people find and talk to one another. They associated this with firms offering highly customised solutions, and gave Bain, Boston Consulting Group and McKinsey as examples.

The authors argued that the choice between them was central to knowledge management, and warned that trying to pursue both equally could undermine a business. Later commentators have questioned whether the choice is really so clean. But the distinction remains useful for tribal knowledge. Some of it can and should be written down. Some of it is best kept alive by making sure people learn from one another.

Codification methods

Standard operating procedures and work instructions. Written step-by-step descriptions of how a task is done, ideally created with the people who do it and kept up to date.
Visual and video instructions. Photographs, diagrams and short videos often capture physical skills better than text.
Checklists. Short lists of critical steps that are easy to skip, used at the point of work.
Runbooks and playbooks. Common in IT operations, these describe how to handle known situations and incidents.
Comments, commit messages and design records. In software, explaining why something is done is often more valuable than describing what the code does.
Knowledge bases and wikis. Searchable collections of answers, often built from questions people actually ask.
Lessons-learned and after-action reviews. Structured discussions after a project or event about what happened, why, and what to do differently, with the results recorded.
Expert interviews before departure. Structured interviews with people who are about to retire or leave, aimed at the decisions, contacts and exceptions they handle.

Personalisation methods

Mentoring and apprenticeship. Pairing experienced and newer employees over months or years, the oldest method of all.
Job shadowing and pairing. Having two people do a task together, such as pair programming in software or side-by-side work on a shop floor.
Job rotation and cross-training. Moving people between roles so more than one person can do each critical task.
Communities of practice. Groups of people across an organisation who share a craft or problem and meet regularly to exchange experience, following the ideas of Lave, Wenger, Brown and Duguid.
Expertise directories. Systems that help people find who knows what, even when the knowledge itself is not written down.
Phased retirement and rehiring retirees. Keeping experienced people involved part-time while they hand on what they know.
Storytelling. Deliberately making room for the kind of war stories Orr described, for example in team meetings or incident reviews.

A historical example: Training Within Industry

One of the most systematic efforts to spread workplace know-how came from the United States during the Second World War. The Training Within Industry (TWI) programme ran from 1940 to 1945 and became part of the War Manpower Commission in 1942. It had to train huge numbers of new workers quickly as experienced men left for military service. TWI taught supervisors short, structured methods. The best known, Job Instruction, built on Charles Allen's four-step method of preparation, presentation, application and testing. Supervisors learned to break a job into steps, identify key points and reasons, demonstrate, have the learner try, and follow up. By the end of the war, over 1.6 million workers in more than 16,500 plants had received TWI certification.

After the war, TWI methods were taken to Japan. Sources commonly say Toyota adopted them in the early 1950s, and they are often credited as an influence on Toyota's practices of standardised work and continuous improvement (kaizen). Much of that account comes from consultants and TWI advocates rather than scholarly histories, so the strength of the influence is best treated as plausible rather than precisely documented. TWI's core idea is directly relevant to tribal knowledge. An experienced worker's know-how can be broken down, made explicit as key points, and taught deliberately, rather than left to be picked up over years.

Making capture work: practical principles

Experience across these methods suggests some general principles. They are distilled from the approaches above, not from a single study.

Start with risk. Identify which knowledge would hurt most to lose: tasks only one person can do, systems only one person understands, relationships only one person maintains. The bus factor is a useful prompt.
Capture the why, not just the how. Procedures go stale. Reasons help people judge when a rule still applies.
Involve the experts as authors, not just sources. Knowledge written by the people who do the work is more accurate and more likely to be used.
Test what you capture. In the Six Sigma spirit, treat captured beliefs as hypotheses where possible, especially when they drive important decisions.
Make it findable. A document nobody can find is just another form of tribal knowledge.
Keep it alive. Assign ownership and review dates. Outdated documentation can be worse than none, because people trust it.
Combine methods. Pair documents with mentoring, rotation and communities. Szulanski's findings suggest that relationships and the receiver's background knowledge matter as much as the material itself.
Reward sharing. If knowledge sharing is invisible in performance reviews and squeezed out by deadlines, Bertain's paradox will persist.

How tribal knowledge looks in different fields

The same pattern turns up almost everywhere, but it takes different forms.

Manufacturing and maintenance

On factory floors and in maintenance shops, tribal knowledge is often sensory and physical: how a machine sounds when a bearing is starting to fail, how a weld pool should look, how much to adjust a setting when raw material comes from a different supplier. It is closely tied to particular equipment, which is why it is so often lost when old machines are kept running long after the people who installed them have left. Orr's copier technicians are a classic example from field service. Quality methods such as Six Sigma treat this knowledge as both a resource and a hypothesis: something to gather from operators and then check with data.

Software and IT operations

In software, tribal knowledge hides in the reasons behind code and configuration. Code itself is explicit, but the purpose of an odd-looking line, the history of a design decision, or the manual steps needed to recover a failing system often live only in a few engineers' heads. Because software teams can measure who has written which parts of a codebase, the bus factor or truck factor has become a common way to talk about the risk. Common responses include code review, so that at least two people understand every change, along with design records, runbooks for incidents, and rotating on-call duties so that knowledge of production systems is spread.

Healthcare

Hospitals depend on both formal protocols and the unwritten knowledge of experienced staff: which equipment behaves oddly, how a particular ward or clinic really works, which consultant expects what. Handovers between shifts are a point where such knowledge either passes on or is lost. Structured handover formats and checklists are partly an attempt to make the most important parts of that knowledge explicit, while leaving room for the experienced judgement no checklist can hold.

Public sector and long-lived institutions

Government agencies, utilities and research laboratories often run systems and programmes for decades. Their staff may spend whole careers there, building deep knowledge of past decisions, legal history and how processes really work. DeLong's examples of early adopters of knowledge retention, such as Sandia National Laboratories and the Tennessee Valley Authority, come from this world. The NASA case shows the same risk on a grand scale: a programme can end, its people disperse, and decades later the organisation finds that the drawings survive but much of the know-how does not.

Small businesses

In a small firm, tribal knowledge may be concentrated in one or two people, often the founders. Supplier relationships, pricing logic, customer histories and the way the books are kept may exist nowhere but in their heads. That is efficient while they are present, and a serious problem when they want to sell the business, step back or fall ill. Succession planning in small businesses is, in large part, a tribal knowledge problem.

Criticisms and limits

Not everything can be written down

If Polanyi was right that "we can know more than we can tell", then some tribal knowledge will always resist capture. A thick manual cannot make someone a skilled surgeon, mechanic or negotiator. Efforts that try to replace experienced people entirely with documents or software tend to disappoint. The Saturn V story shows that even a deliberate, well-funded retention programme could keep the drawings but not all the know-how.

Knowledge management's own critics

The broader field of knowledge management has been criticised as faddish. In 2002 the information scientist T. D. Wilson published "The nonsense of 'knowledge management'" in the journal Information Research. He examined journal articles, consultancy websites and business school materials. He concluded that the label covered a range of different activities, none of which actually managed knowledge. Those that did not simply manage information were really aimed at changing work practices, on the assumption that better communication would lead to more sharing. He also recorded a rapid rise in publications using the term from 1997 onward. Critics in this vein argue that the useful core of knowledge management is old common sense: train people, write things down sensibly, encourage communication.

Documentation can create false confidence

A captured procedure can give the impression that knowledge is safe when the crucial judgement is missing. Brown and Duguid's distinction between work as described and work as done applies here. Organisations can end up with large repositories that describe the work as designed, not as actually performed.

Tribal knowledge can be wrong

Treating every piece of experienced workers' knowledge as wisdom is as risky as ignoring it. Some long-standing practices are superstitions, outdated workarounds or habits that once had a reason. Separating the valuable from the mistaken needs testing, discussion and data.

Power and fairness

Asking people to give up the knowledge that makes them valuable, especially just before layoffs or outsourcing, raises obvious concerns. Employees may reasonably fear that documenting their knowledge makes them easier to replace. Capture efforts work better where people trust that sharing will be recognised and rewarded, not used against them.

A wider meaning: traditional knowledge

The word "tribal" has another sense outside business. In anthropology and ethnobotany, "tribal knowledge" can refer to the traditional knowledge of indigenous peoples, such as knowledge of plants, medicines, land and ecology passed down orally. The ethnobotanist Paul Alan Cox's 2000 article in Science, "Will tribal knowledge survive the millennium?", addressed the risk of such knowledge being lost as languages and traditional ways of life disappear. Geoffrey Bowker's 2002 essay "Keeping knowledge local" explored related questions about local knowledge and its relationship to formal information systems. These works concern a different setting from corporate tribal knowledge. They share the central concern: knowledge held in living people and communities can vanish within a generation if it is not passed on.

Common misconceptions

"Tribal knowledge is the same as tacit knowledge." They overlap, but they are not identical. Some tribal knowledge is easy to state, such as a customer's invoicing quirk. It just has not been written down. Some tacit knowledge, such as a fine motor skill, may never be fully stated.

"Good documentation eliminates tribal knowledge." It reduces dependence on it, but new tribal knowledge forms constantly as work changes. Managing it is continuous work, not a one-time project.

"Tribal knowledge is always a problem." Informal knowledge sharing is how people learn and how organisations adapt. The problem is concentration and fragility, not the existence of unwritten know-how.

"Software tools solve it." Wikis, knowledge bases and search tools help, but Szulanski's research suggests that the biggest barriers are understanding and relationships, not access to documents.

"It only matters when people retire." Knowledge is also lost through resignations, reorganisations, illness, outsourcing and simply forgetting. DeLong's framework explicitly includes mid-career departures.

Frequently asked questions

How can an organisation find out where its tribal knowledge is?

Common starting points are asking teams which tasks only one person can do, mapping who gets asked for help most often, reviewing what slows new employees down, and noting what goes wrong when particular people are away. In software, tools that analyse who has written and changed code can estimate a project's bus or truck factor.

Is it worth documenting everything?

No. Documentation costs time and must be maintained. The most useful targets are knowledge that is critical, held by few people, and stable enough that a written version will stay accurate for a while.

What is the single most effective method?

Research and practice both suggest there is no single best method. Combining written records with deliberate person-to-person learning, such as mentoring, pairing and rotation, tends to work better than either alone.

Does the term "tribal knowledge" have any negative connotations?

The phrase borrows an analogy from anthropology. Wikipedia's article notes that some consider it jargon. Related terms such as "institutional knowledge", "organisational memory" and "undocumented know-how" describe overlapping ideas, and organisations can choose whichever term suits them.

How is tribal knowledge different from expertise?

Expertise is a person's deep skill and knowledge in a field. Tribal knowledge is more specific: the local, often undocumented knowledge about how things work in this place, with these machines, customers, systems and people. An expert joining a new organisation still has to learn its tribal knowledge.

Can tribal knowledge be a competitive advantage?

Yes. Knowledge that is hard to write down is also hard for competitors to copy. Szulanski's study begins from the premise that the ability to transfer best practice internally is critical to building competitive advantage. The challenge is keeping the advantage of distinctive know-how without the fragility of depending on a few individuals.

Summary

Tribal knowledge is the unwritten know-how that lets an organisation actually function: the exceptions, workarounds, judgements, relationships and stories that formal systems miss. It forms naturally, because documentation lags practice, some knowledge resists description, and people share most readily with those they know. Research from Polanyi's theory of tacit knowing to Orr's study of copier technicians and Szulanski's work on internal "stickiness" explains why this knowledge is so valuable and so hard to move. It creates real risks, made concrete by the bus factor and by cases like the lost manufacturing know-how behind the Saturn V's engines. Organisations manage it by combining codification, writing things down well, with personalisation, making sure people learn from one another. They must also stay realistic that some knowledge can never be fully captured, and that some of what has always been "known" may turn out to be wrong.