It's only natural that over time, as teams grow and codebases change, projects acquire an oral history. Newcomers may look at the code askance and wonder why a particular way of structuring the code was taken, or why this module is written this way, but this one (over here) is written that way. The problem is that this oral history is normally spread between lots of different people, and these people have a habit of not always being available when you're puzzling over something that looks like a cack-handed design decision. Surely, you ponder, because everyone on the team is working to the best of their abilities, this must have been done this way deliberately. Things get even more tricky when people leave a project, taking their store of oral history (sorry, implicit knowledge) with them.
Now, the most common way that I've seen this addressed is to assiduously update the project wiki, which works just fine until the second week of effort when the pressures of delivery finally eat away at the "spare" time it takes to keep everything up to date. Another way to cope is to limit the rate at which people join and leave the team, attempting to spread the implicit knowledge to as many people as possible. This leads to humorous discussions as people remember different aspects of a particular decision or phase of the project, but doesn't resolve the root issue that there's no readily accessible source of truth to talk to about why Things Are the Way They Are.
Enter the Project Shaman. She's responsible for being the Fountain of Stories about the history of the project. She remembers all the important turning points, the amusing stories, and the reasons behind all those strange choices now enshrined in the plastic mess of the codebase. I always imagine that she can impart the stories with a certain light-hearted humour, but I suppose you could have some grim-faced, dour soul. The important thing is that a team now has a Source of Truth, who remembers the ways of the ancients and can shed light on even that darkest of mysteries: a large codebase.
But what to do when your trusted, knowledgable Shaman decides to leave? Haven't we just introduced a single point of failure? If she goes, then your entire team has lost its oral history. Well, in all but the most tragic of circumstances, there's normally some kind of warning that the Shaman's about to leave, giving her plenty of time to pass on the story of the project to another person. This is made easier if the Shaman has been sharing stories on a regular basis, and it helps that there tend to be only a few areas in a codebase that make people frown and wonder aloud how it came to be that way. Admittedly, some of those areas might be pretty big, but that's another point entirely! Finally, just because there's a Shaman, there's no reason why the ad hoc gathering of stories and history that always goes on in a project can't still occur. I know that last point is a direct contradiction of what I said earlier, but the Shaman brings efficiency to the process of recall, she doesn't replace it.