I used the term "tribal knowledge" at work earlier this week, and folks didn't know what I meant. It's a term that we used to use around the office all the time at several of my past jobs, and I thought it was common jargon, but apparently not.
Tribal knowledge is when everyone knows stuff, so you don't need to write it down. Everyone just knows. And when you don't know, you know who to ask, right?
So, if you want to know where the good fishing holes are, you ask Uncle Joe, and he'll show you where they are. You could ask Ron, but he hasn't been fishing in a while, and there was that storm last month, and it knocked some trees down, so you can't be sure.
If you want to know about fixing your car, you ask Frieda, because she's always tinkering with cars, and she knows all about them. But she's a bit secretive, and she'll probably prefer to just fix it for you than to tell you how to fix it.
If you need a new watch, Vinnie can get you one - he knows this guy - but you can't get them yourself, because that might tip off The Man, and then the supply would dry up.
Thus, over time, it turns out that nobody knows anything, and in order to get anything done, you have to know who to ask to find out who to ask, and all the wisdom of the tribe is squirreled away in these secret repositories of hidden knowledge. Of course, when Frieda moved to Chicago, nobody could fix their car any more, and when Uncle Joe got eaten by that alligator nobody knew where the fish were biting.
And it's the same way when little bits of knowledge aren't captured in any kind of documentation at work. Some people do this because they enjoy the power of being The One Who Knows, and others do it because they think it's job security, but most people do it because ... well, they just don't think of it. There's so many things to do, and writing down that the creamer is kept in the cabinet on the far left just isn't important. After all, everyone knows, right? And if you don't, you can ask Bertha where it is.
Documentation is not wasted time. Documenting processes is an investment in future productivity - possibly even your own, because you'll forget. Code comments today save hours of work next week. Documenting the arguments that are passed to a function will save me having to search through dozens of source files to find examples of how it is called.
Tribal Knowledge is a very damaging thing to your project and your company, because people leave. They move on to other jobs. They get assigned to other projects. And, even more often, they just forget. The half-life of unused knowledge is awfully short. And then someone else has to become The Expert, and pretty soon they find that they're the one that gets the annoying phone calls at 5:16pm, on their way to their daughter's orchestra concert, to explain how to insert the flywheel onto the grommet. So write it down. Put it in the wiki. Tell everyone where the information is, and encourage them to put their information there too.
This is where distributed OSS development has an edge: with all discussions by email and issue tracking, there's a vast indexable collection of knowledge.
It's therefore why at work I'm obsessive about having a JIRA issue for every failing test -with stack trace, for discussions to go via JIRA and email rather than someone corner me in the corridor -to build up that history as you go along. Operations/deployment work is stuff you need to file bugreps too, to keep track of their issues.
That said, there's nothing more depressing than getting a stack trace, putting the first line into google, and finding out the only person to ever hit this bug, six months earlier, was you.
BUT, don't also forget that 'documentation' also has half-life and very quickly becomes stale, people forget what is written down and where, most things exist in many places, things you read are out-dated and sometimes even wrong (which can be worse than no information). Documentation is a living organism, and documenting too much will create an endless maintenance problem. Hence, I like to do what SteveL does; Keep everything in a evolving knowledgebase that is indexable, searchable by relevance/age and what not. Issue trackers are great and email (like GMail) an excellent complement.
When documenting; Write very little (prose is tiresome to read when searching for solutions), as condensed as possible and use dynamic media (like email) for filling the holes...
Documentation isn't knowledge. Knowledge is what is in my head. Or yours.
Documentation is a record of what we know. If the software changes, the documentation needs to change. As Niclas said above, that doesn't always happen.
However, documentation is aimed at specific readers.
If you write for developers, you want clear code, and comments on why something was done the way it was. This documentation can and will change pretty fast. Email/IRC logs are great for this.
If you are writing for sysadmins, then you want to document failure modes, installation and configuration options and how to monitor the software. This changes far more slowly.
If you are writing for end users, then you document behaviour. This documentation will change the slowest, because it describes your business requirements.
The hardest documentation to write is aimed at people who have to debug the system. This needs to change as fast as developer documentation, and deal with a lot of *what* is happening.
This sort of documentation is almost never written down (writing down stuff which deals with bypassing bugs isn't useful, you just fix the bug instead). This is where you need the expert, and is generally passed on via apprenticeships and word of mouth. This is tribal knowledge and it needs to be baked into code (source or configuration management).
At 71, and a year beyond my "best used by" date, I find my chief asset for the company I work for on a part time basis is providing history and "the way things used to be before we all killed our brains with an electronics overdose". I work in mechanical/civil engineering by the way. I also keep up with the "kids in the hall" on advanced structural computations and it is here that my knowledge gleaned from 50 years is invaluable in guiding analysts to developing good models, checking results by independent means and generally providing a framework to support work which does not seem to be provided to college graduates these days. I refer to their way of working as giving "more buck for the bang" it is so inefficient in its use of known (once) principles and facts. I thought "tribal knowledge" might refer to this sort of cumulative knowledge but, after reading a few descriptions I think not. What I and my old fart contemporaries know could be written down, but nobody would have the time to do so, or read it. Better to pass it on in the context of jobs done and let individuals make their own notes.