Knowledge is one of those things we take for granted. It's far easier to recognize its absence than to define what it is, or to capture or record it. All of this means (to quote Joni Mitchell), that we don't known what we got till it's gone.
For example: your software project is humming along, everything is on track, and suddenly Joe, your lead developer gets hit by a bus ('Bus Error!'). Or perhaps he just announces that he's gotten a much better job offer on the other side of the country. Grrr.
What walked out the door with Joe? If you're like most software companies, more than you can really afford. Will your software even build without Joe typing some cryptic sequence of commands, manually supplying some configuration parameters, hitting some button or typing a secret password? Do you know what Joe was planning to do to make all the pieces fit together, and how, and why? What are those pieces, where do they live, and how do they depend on each other? Do you actually have a working build of your software? How do you know it's working?
By now you probably are hyperventilating, and your palms are a bit sweaty. Relax, take deep slow breaths... you know how to minimize these risks.
If you look at the scenario above closely, you'll see that there are two distinct types of knowledge. One of them is about what Joe does. The way to minimize the impact of Joe's departure is to automate as much of what he does as possible. This has other benefits. It frees him to do more creative things (writing immortal code, or looking for a better job - but dealing with that is another topic!) It ensures that everything that is done is exactly repeatable - this isolates variables, which helps in testing and other aspects of development and the software process). It ensures that tasks get done, even if they are boring (running unit tests) or developers are distracted by more important tasks (like getting the demo release out on schedule)
The other aspect of knowledge is about intentions, reasons, history, discoveries, opinions, stories, lore, learning, preferences, culture.... For this kind of knowledge to be shared, there must be the right context. Academic institutions tend to foster the sharing and cultivation of knowledge, by providing contexts for people to study, share what they learn, and engage in dialogue and debate. They invent and standardize language and models so as to permit one scholar to enter the mind of another and share his knowledge via their common language, culture and references.
Businesses tends to lean more to the ideal of keeping information proprietary and reducing interdependencies among people required to perform job tasks. Many businesses view themselves as operating according to a very mechanistic model, with people performing as interchangeable 'roles' or units within 'business processes' and flows. This makes it difficult for one employee to know what any other employee knows with respect to his or her job. In order to break down the 'siloing' of information, organizations must adopt strategies which work to influence the behaviour of their members to communicate. For example, to the extent that it can be done without sharing information which is proprietary, if employees can publically blog about issues related to their work, this benefits the employee by boosting his social standing/rank, establishing expert credentials. By the same token, this can improve the visibility of the company, conferring technical credibility.
Other vital contexts are formal and informal exchange. While I recognize the truth of the assertion that software development requires long periods of uninterrupted concentration and focus, I think it is also important to ensure that technical people be encouraged to share their knowledge in formal contexts such as seminars or presentation, preferably focused in the context of a work project, and in informal contexts such as a scheduled coffee/tea (or beer/pizza) hour.
Do you have a very easy to use Snippets/FAQ/How-to repository, accessible to all (via Wiki or other on-line collaborative technology)? Is contribution there recognized and rewarded?