What Is Tacit Knowledge? (And Why It Never Makes It Into Your Systems)

Every company has a version of this problem: the person who “just knows” how a system actually behaves, which client always pushes back on renewal terms, or why a particular workaround exists in the code. None of that is written down. It doesn’t need to be — until the person who knows it takes a new job, and suddenly nobody does.

This is tacit knowledge, and it’s a different problem from the one most knowledge-management tools are built to solve.

Tacit knowledge vs. explicit knowledge

Explicit knowledge is anything that’s been written down and can be looked up: a runbook, a policy PDF, a Confluence page, a Slack thread with an answer in it. It’s imperfect — it goes stale, it’s scattered across tools — but it exists as an artifact someone else can find.

Tacit knowledge never became an artifact in the first place. It’s the reasoning behind a decision, not the decision itself. A support engineer who can tell within thirty seconds whether a bug report is “the usual thing” or something new isn’t consulting a document to make that call. They’re pattern-matching against hundreds of past cases they never wrote up.

Why “just document it” doesn’t work

The standard fix for institutional knowledge gaps is some version of “let’s get people to document their processes.” For tacit knowledge, that instruction mostly fails, for a specific reason: the person holding the knowledge usually doesn’t experience it as knowledge. It feels like common sense, not like a fact worth writing down.

Ask a senior engineer to document “everything they know” about a system and they’ll write a reasonably complete architecture doc — and still leave out the judgment call they make every time a specific error pattern shows up, because that judgment call doesn’t feel like a discrete fact to them. It feels like just knowing what to do.

Where this shows up hardest: fast-moving, high-judgment teams

Tacit knowledge loss is sharpest in roles where decisions are made faster than documentation can keep up: trading desks, incident response, sales negotiation, compliance review. In each case the person doing the work is making dozens of small judgment calls a day that never get written down anywhere, because writing them down would slow down the work they’re actually there to do. This is a familiar pattern in financial services, where front-office judgment calls rarely make it into any system of record.

At scale — a company with thousands of employees spread across regions, functions, and tools — this compounds. The knowledge that would help a new hire, or a different team facing the same situation for the first time, exists somewhere in the company. It’s just not accessible to anyone except the person who already has it. That’s a close cousin of what we’ve called the Context Tax: the compounding cost of knowledge nobody can find.

What actually captures tacit knowledge

The tools that make progress here don’t ask people to document more. They capture tacit knowledge as a byproduct of work that was already happening — the questions people ask, the answers experts give, the reasoning behind a decision when it’s made — and turn that into something reusable, cited back to the person and context it came from.

That’s a different design point than a wiki or a search tool. It means treating every real question-and-answer exchange inside the company as a potential unit of institutional knowledge, rather than waiting for someone to proactively write a document nobody asked for. It’s also why an AI system that only answers questions, without acting on or updating anything, is a meaningfully different tool than an AI agent built to act — tacit-knowledge capture sits squarely in “answers” territory.

How SphereIQ approaches this

SphereIQ’s Company Brain is built around this exact gap. It captures knowledge from where it actually happens — the questions people ask and the answers experts give, across the tools your teams already use — and turns it into a governed, cited layer that traces every answer back to its source. Each sourced answer stays traceable through the Enterprise Twin, so you can see exactly which document, person, or system an answer came from.

It isn’t a substitute for documentation. It catches the knowledge that documentation efforts structurally miss: the tacit kind. That’s a related but distinct problem from what happens when a tenured employee leaves. That piece covers the person leaving with their knowledge; this one covers knowledge that was never written down even while they were still there.

Frequently asked questions