Tacit Knowledge in Enterprise Software Teams: What It Is and Why It Matters

The knowledge your wiki cannot hold

The concept of tacit knowledge comes originally from the philosopher Michael Polanyi, who described it with the observation that "we can know more than we can tell." It has since been elaborated extensively in organizational theory and management science, but the core insight remains: much of what makes an expert productive is knowledge they cannot fully articulate, even when asked directly.

For enterprise software teams, this manifests in specific, consequential ways. The senior engineer who knows which alerts from the monitoring system actually indicate a real problem versus which are noise from a known quirk in the health check implementation. The product manager who knows that a particular stakeholder's stated preference reliably diverges from their actual preference once you get to implementation. The operations lead who knows that the quarterly close process actually depends on a sequence of informal handoffs between two teams that is not represented anywhere in the formal process documentation.

None of these people would deliberately withhold this knowledge if asked to document it. The problem is that much of it is not consciously recognized as knowledge that needs documenting. It is simply how work is done, invisible to the person doing it in the same way that a fluent speaker of a language is not consciously aware of its grammatical rules while using them.

The explicit-tacit spectrum

Explicit and tacit knowledge are not two discrete categories but endpoints of a spectrum. Some knowledge is cleanly explicit: the API endpoint for a service, the password rotation policy, the process for requesting infrastructure changes. These can be written down accurately, read by someone who was not present when the process was designed, and applied reliably.

As you move toward the tacit end of the spectrum, the knowledge becomes harder to transfer through documentation alone. At the near-tacit end, you find things like calibrated judgment under uncertainty: knowing when a situation is routine enough to handle with a standard playbook versus when it requires escalation to someone with deeper context. At the fully tacit end, you find the expertise that experts themselves often cannot describe: the pattern recognition that lets an experienced engineer look at a production incident trace and immediately identify the likely root cause in a way that a less experienced engineer, reading the same trace, cannot replicate.

The practical implication is that you cannot solve the tacit knowledge problem by writing better documentation. Documentation is a tool for preserving and sharing explicit knowledge. For tacit knowledge, it is at best a partial aid. The more fully tacit the knowledge, the less documentation helps and the more the transfer depends on situated practice with an experienced practitioner.

Where tacit knowledge sits in enterprise software teams

In our work with growing software teams, we see tacit knowledge concentrated in three areas that are particularly relevant from a dependency risk perspective.

The first is system-specific operational judgment. Every production system has behavior that is technically correct but practically counterintuitive. Engineers who have operated a system for long enough develop reliable intuitions about when something that looks concerning is actually fine, and when something that looks fine is actually a harbinger of a problem. This judgment is built through accumulated experience with that specific system. It cannot be transferred by documenting the system's behavior, because the whole point of the judgment is that the behavior does not straightforwardly tell you what it means.

The second area is organizational navigation knowledge. Large organizations have formal processes and informal realities that diverge significantly. An experienced team member knows which formal approval process can be fast-tracked if you frame the request correctly, which cross-team dependencies require a direct conversation rather than a ticket, and which stakeholders need to be brought in early versus which ones are fine being informed after the fact. This knowledge is critical for actually getting things done at a reasonable pace, and it is almost entirely person-specific and context-specific. No wiki page will ever reliably encode it.

The third area is decision context history. Modern software systems are built on layers of accumulated decisions, most of which are not documented anywhere and many of which were made by people who are no longer at the organization. When something breaks in an unexpected way, the people who understand why the system was designed the way it was are often the only ones who can reason effectively about the failure mode. When those people leave, that decision context is gone. The team is left with the outcome of the decisions but not the reasoning, which makes maintenance and evolution of the system significantly harder.

Why this matters for dependency risk specifically

The reason tacit knowledge is central to dependency risk is straightforward: it is the hardest knowledge to replicate when the person holding it becomes unavailable. A process that is fully documented with accurate, complete explicit knowledge can be executed by someone who was not involved in its original design. A process that depends on tacit judgment cannot be, regardless of how good the documentation is.

When you are scoring dependency risk, the distinction between explicit and tacit knowledge should be a major factor. A single-person dependency on a process that is well-documented and relies primarily on explicit knowledge is a lower-risk situation than a single-person dependency on a process that requires significant tacit judgment and operational experience to execute reliably under non-standard conditions. Both are risks. They are not equivalent risks.

This is one of the places where activity-signal analysis gives you information that documentation audits cannot. If a particular process generates repeated questions to a specific person, that is a signal that the knowledge required to execute it is not fully captured in the explicit documentation. The questions themselves reveal where the tacit gaps are. A process that people can execute without generating questions to its owner is much more likely to have adequate documentation than one that consistently prompts requests for clarification from the person who holds the operational experience.

The limits of codification

There is a reasonable question about whether better tooling for knowledge capture can close the tacit gap over time. The short answer is: partially, for some knowledge types, and not at all for others.

For the near-tacit end of the spectrum, structured capture tools can help. If you build the habit of creating decision logs when making significant architectural choices, you can preserve more of the reasoning than a code commit alone would. If you record operational runbooks with enough specificity to include edge cases and the reasoning behind exception handling, you can push more tacit judgment into the explicit range. This is worth doing and consistently underdone in most teams.

For the fully tacit end, codification does not work as a transfer mechanism. You cannot write down pattern recognition that experts themselves cannot fully articulate. The transfer mechanism for this knowledge is apprenticeship and situated practice: junior team members working closely with senior ones, having the experience of watching the expert respond to real situations and being coached through their own responses. This is time-intensive and organizationally difficult to scale, which is why it is underprovided and why the tacit gaps accumulate faster than most teams realize.

We are not suggesting that this problem is fully solvable with any tooling. The point is to measure it accurately enough to make informed decisions about where to invest in mitigation, rather than assuming the documentation system is covering knowledge risks that documentation is structurally unable to cover.

Mapping tacit knowledge exposure

If you cannot fully capture tacit knowledge, the next best thing is to know where it lives and who holds it. This gives you enough information to make deliberate decisions about coverage: who should be working closely with which knowledge holders to absorb the tacit context that cannot be documented, which processes are most exposed to single-person tacit dependency, and which departures are likely to leave the most significant tacit gaps.

The signals for where tacit knowledge is concentrated are mostly behavioral. Who does the team route its most ambiguous or high-stakes questions to? Whose input is sought on decisions even when they are not formally responsible for the outcome? Which processes generate repeated questions to the same person rather than being executable from documentation alone? These patterns in the organizational activity data are a proxy for where the tacit knowledge concentration is highest, and therefore where the dependency risk from tacit knowledge gaps is most acute.

That is ultimately the frame Brekfuz brings to this problem. Not "how do we capture tacit knowledge" but rather "where does tacit knowledge create dependency risk that is not visible in the documentation structure," so that teams can see those risks and address them through deliberate coverage choices before an unavailability event makes them concrete.