Some of the most valuable knowledge in your organization isn’t written down anywhere
There is a moment in almost every IT incident where documentation runs out.
You follow the runbook. You check the logs. You review recent changes. And then, when none of it explains what is happening, someone says, “Let me take a look.” Within minutes, they identify the issue, often based on a pattern they have seen before, a subtle signal in the system, or simply a gut instinct built over years of experience.
That moment highlights one of the most important, and often overlooked, dynamics inside modern organizations: not all knowledge is created equal.
Broadly speaking, organizations operate on two types of knowledge. The first is explicit knowledge, which includes anything that can be written down, documented, and shared. The second is tacit knowledge, which lives in people. It is built through experience, shaped by context, and often difficult to articulate.
Both are essential. Most organizations are only truly good at managing one.
Explicit knowledge is the foundation most organizations are built on. It includes procedures, documentation, reports, and structured data. It is the system configuration guide that walks a new engineer through a setup. It is the knowledge base article that outlines how to resolve a known issue. It is the standard operating procedure that ensures consistency across teams.
This type of knowledge scales well because it is transferable. Once documented, it can be reused, distributed, and improved over time. It enables onboarding, supports automation, and reduces dependency on individual contributors. In many ways, it is the backbone of operational efficiency.
Organizations have become increasingly sophisticated in how they capture and manage explicit knowledge. Internal documentation platforms, structured knowledge bases, and integrated system notes all play a role. Even small habits, like updating documentation after a system change or capturing lessons learned after an incident, can significantly improve how knowledge flows across a team.
As discussed in To Scale Your Company’s Knowledge, Build A Documentation Culture, organizations that prioritize documentation create a foundation that allows knowledge to grow alongside the business. Without that foundation, scaling becomes difficult, and critical knowledge remains fragmented.
But explicit knowledge has limits.
It tells you what to do, but not always why it works. It can guide you through known scenarios, but it struggles in unfamiliar situations. It is structured, repeatable, and reliable, but it cannot fully capture the nuance of real-world decision-making.
That is where tacit knowledge comes in.
Tacit knowledge is harder to define because it is not something you can easily point to. It is the ability to recognize a pattern in system behavior that is not documented anywhere. It is the instinct to check a specific dependency because something feels off. It is the accumulated experience of solving similar problems over time.
In practice, tacit knowledge is often what separates a competent team from a highly effective one.
It is also the knowledge most at risk of being lost.
When organizations rely too heavily on individuals without capturing what they know, they create hidden dependencies. A single departure can result in significant knowledge gaps. A lack of shared understanding can slow down troubleshooting, increase risk, and limit innovation.
The challenge is that tacit knowledge does not fit neatly into systems.
You cannot simply document intuition or experience in the same way you document a process. Attempting to do so often results in oversimplification, stripping away the very context that makes the knowledge valuable.
Instead, tacit knowledge must be captured through interaction.
This is where organizational design becomes critical. Teams that create space for collaboration tend to capture tacit knowledge more effectively. Mentorship programs allow less experienced team members to learn directly from those with deeper expertise. Shadowing provides exposure to real-world decision-making. Cross-functional work encourages knowledge to move between teams rather than staying siloed.
One particularly effective approach is the use of team liaisons. By embedding individuals who can bridge technical and business perspectives, organizations create natural pathways for knowledge transfer. As described in State of the CIO 2003 Best Practive #6: Assign Liaisons to Business Units, this model helps surface insights that might otherwise remain isolated within specific teams.
From a practical standpoint, some of the most valuable knowledge transfer happens in conversations that are not formally structured. A quick discussion after an incident. A walkthrough of how a problem was solved. A shared review of a complex issue. These interactions often reveal more than any documentation ever could.
This creates an interesting tension.
Organizations need structure to scale, but they also need flexibility to learn. Too much emphasis on documentation can create rigid processes that fail in dynamic situations. Too little emphasis leaves teams dependent on individuals and vulnerable to knowledge loss.
The goal is not to choose one over the other. It is to design systems that support both.
Strong organizations treat explicit knowledge as a baseline. Documentation is expected, maintained, and continuously improved. At the same time, they invest in environments where tacit knowledge can be shared. They encourage collaboration, prioritize communication, and recognize that not everything of value can be written down.
In many ways, this balance resembles something out of science fiction.
If explicit knowledge is the archive, the structured database of everything that has been learned, then tacit knowledge is closer to the Force. It is harder to define, shaped by experience, and often felt before it is fully understood. Both are powerful, but only when used together.
For leaders, this has direct implications for how teams are built and managed.
Hiring decisions should consider not only technical skill but also the ability to share knowledge. Performance should reflect contributions to both documentation and team learning. Processes should include not just what needs to be done, but how knowledge is captured along the way.
For example, incident management can be structured to support both types of knowledge. The resolution itself becomes explicit knowledge through documentation. The discussion around how the issue was identified and solved becomes an opportunity to share tacit knowledge. Over time, this approach builds both a stronger knowledge base and a more capable team.
Similarly, onboarding should go beyond providing documentation. Pairing new team members with experienced colleagues accelerates learning in ways that written materials cannot replicate. It exposes them to real-world scenarios and helps them develop the intuition that defines effective performance.
Even small adjustments can have a meaningful impact. Encouraging teams to talk through their thought processes. Creating forums for sharing lessons learned. Assigning ownership for maintaining documentation while also recognizing the value of informal knowledge exchange.
These are not complex initiatives, but they require intentionality.
Organizations that succeed in this area tend to treat knowledge as a strategic asset rather than an operational byproduct. They understand that information alone is not enough. It is how that information is captured, shared, and applied that creates value.
Over time, this approach leads to better decision-making, faster problem resolution, and more resilient teams.
It also changes how people experience their work.
When knowledge is shared effectively, individuals are not isolated within their roles. They become part of a larger system where learning is continuous and collaborative. This not only improves performance but also increases engagement and retention.
In contrast, environments that fail to manage knowledge effectively often feel fragmented. Teams operate in silos. Critical information is difficult to find. Progress depends on knowing the right person rather than accessing the right resource.
The difference between these two environments is not technology. It is how knowledge is treated.
Explicit knowledge provides clarity. Tacit knowledge provides depth. Together, they create a more complete understanding of how work gets done.
And in a world where systems are becoming more complex and change is constant, that understanding is no longer optional. It is the difference between reacting to problems and anticipating them.


Leave a Reply