Communities as the Unit That Blends Tacit and Explicit Knowledge

Definition

Explicit, documented knowledge is never self-sufficient — applying it correctly still depends on tacit understanding the document can't carry. Because communities of practice hold both the codified material and the shared tacit understanding of when and how to use it, they — not IT systems working alone — are positioned to turn documentation into something people actually use.

In the Book

The book distinguishes tacit knowledge ("we know more than we can tell") — embodied expertise enabling dynamic responses to context-specific problems, hard for competitors to replicate — from explicit knowledge that can be written down. Sharing the tacit part requires "interaction and informal learning processes such as storytelling, conversation, coaching, and apprenticeship," the kind communities of practice naturally provide. The book grounds this in the Chrysler case from chapter 1: an earlier attempt to build an Engineering Book of Knowledge had failed, and general knowledge-management projects run purely by IT departments produced "digital junkyards" — one consulting firm's audit found 1,100 databases, only thirty active, twenty of those just news feeds. The EBoK succeeded on its second attempt specifically because Tech Club members took ownership of creating and maintaining it themselves, treating it "as part of what their community is about" rather than as a separate IT deliverable imposed on them.

Why It Matters

This gives a diagnostic for why a documentation or knowledge-capture initiative fails even when the content itself is accurate: the content was extracted from a community rather than owned by one. It reframes "who should own this wiki/playbook/database" from an administrative question into a design question — ownership has to sit with the group whose tacit understanding makes the explicit content usable, or the artifact decays into an unused repository regardless of how well it was built.