The System That Teaches Nothing

There is a pattern I keep seeing in enterprise IT deployments that nobody quite names directly. An organization builds a knowledge base, or a wiki, or a "learning management system," spends considerable money on it, rolls it out with a communications plan and mandatory training sessions, and then watches it slowly die. The pages go stale. The search returns outdated documents. The employees who were supposed to contribute mostly read what's already there, and the ones who were supposed to read it mostly don't. Two years later, IT is asking whether to sunset the platform or migrate it to the next enterprise content system that promises to solve the same problem.

This is not a technology problem. The technology works fine. The issue is what the organization actually wants from learning, and whether the tools it builds are capable of delivering it.

Argyris and Schön, writing in 1978, drew a distinction I keep returning to when I think about this. They separated what they called single-loop learning from double-loop learning. Single-loop learning is the normal correction process: something goes wrong, you detect the error, you fix it, and you continue operating under the same governing assumptions as before. A thermostat is the canonical example. Temperature drops, thermostat fires the furnace, temperature returns to set point. Problem solved. But the thermostat never asks whether the set point is correct. That question, whether the governing assumptions themselves need examination, is what double-loop learning addresses. I want to be transparent that I did not find Argyris and Schön in my local study materials, so I am drawing on the broader organizational learning literature here, and I would hedge any specific claim about their wording. But the distinction between correcting errors within a frame and questioning the frame itself is one of those ideas that becomes impossible to unsee once you have it.

Most enterprise knowledge systems are built for single-loop learning. They capture procedures, guidelines, troubleshooting steps, and compliance documents. They are very good at helping an employee find the right form to fill out or the approved vendor list for a given category of purchase. They are essentially useless for the organizational self-examination that would change what goes on those forms or renegotiate those vendor relationships. The system encodes the current way of doing things. It cannot question it. For single-loop problems, that is fine. For the harder questions organizations actually need to grapple with, it produces the illusion of learning without the substance.

Nonaka's SECI model is useful here, and unlike Argyris, this one I can verify from my study materials. Nonaka (1994) described four modes of knowledge conversion: Socialization (tacit to tacit), Externalization (tacit to explicit), Combination (explicit to explicit), and Internalization (explicit to tacit). The enterprise knowledge system handles Combination well. It reorganizes existing explicit knowledge into new explicit knowledge. It can also support Internalization to a limited degree, helping individuals absorb documented procedures into their own practice. What it almost completely fails to support is Socialization and Externalization. Socialization, the transfer of tacit knowledge through shared experience and observation, requires proximity, time, and a relationship. You cannot SharePoint that. Externalization, converting tacit knowledge into explicit form, is where the real value would be if it happened, but it requires deliberate effort from the person who holds the tacit knowledge and an organizational incentive to do the work. Neither of those things tend to be present in organizations that have just purchased a knowledge platform.

The result is that knowledge systems systematically capture the easy half of organizational knowledge and miss the hard half. The easy half is the explicit, codifiable, policy-and-procedure knowledge that was already being written down before anyone bought the platform. The hard half is the judgment, the contextual wisdom, the "here's what actually happens in practice versus what the documentation says," the relational knowledge about who to call when the process breaks down. That knowledge lives in Slack DMs and hallway conversations and the mental models of senior employees who have been around long enough to know how things actually work. It is invisible to the system. It is also the knowledge that matters most when something goes wrong.

I wrote about the absorptive capacity angle in a previous post, and it connects here directly. Cohen and Levinthal (1990) showed that organizations can only absorb new knowledge if they have prior related knowledge to connect it to. That applies to knowledge systems too. A team that has no established practice of looking up procedures before acting will not suddenly develop that practice because IT installed a new wiki. The prior habit of knowledge-seeking has to exist before the tool can serve it. Organizations with low absorptive capacity in a domain build a knowledge system for that domain and then do not use it, because the cognitive and organizational infrastructure that would make the tool useful is absent. This is why the most sophisticated knowledge platforms tend to be built by organizations that were already sophisticated at managing knowledge, and why they see better results than organizations buying the platform in the hope that the tool will build the capacity.

The irony that the best organizational learning often happens in informal channels is real and persistent. I have seen this described as a failure of implementation, as though the fix is better change management or more mandatory training. But I think it is structural. Informal channels, a DM thread, a shared document, a quick lunch conversation, carry contextual cues that formal systems strip out. They allow the question "what do you actually think about this?" in a way that a tagged knowledge article in a content management system does not. They are also responsive in real time to the specific situation the person is facing, which is the Socialization mode in Nonaka's model. The formal system provides a generalized answer. The informal channel provides a specific one. People rationally prefer the specific answer, which is why the DM gets answered faster than the knowledge base gets searched.

Absorptive capacity adds one more layer to this. Organizations that have built strong knowledge-sharing cultures, that have invested over years in the prior relational knowledge that makes informal channels rich, will have productive informal learning regardless of what system IT deploys. Organizations that lack that culture will have unproductive informal channels and unproductive formal systems simultaneously. The platform cannot substitute for the underlying organizational capacity. It can support and extend it, but it cannot create it.

This is why I think the question organizations should be asking before buying a knowledge management system is not "what features does this platform have?" but "what is our current absorptive capacity for the knowledge we want to manage, and what would it take to build it?" The answer to that question is almost never "buy a platform." It is usually something slower and harder: invest in communities of practice, create structured mentorship programs, build routines for after-action review, give people time and organizational credit for knowledge-sharing work. None of those things are products you can purchase. They are investments in human and social capital that pay off gradually and are difficult to attribute on a quarterly ROI spreadsheet.

The double-loop question Argyris and Schön wanted organizations to ask is whether the governing assumptions are correct. Applied to knowledge management itself, the governing assumption most organizations are operating under is that the problem is storage and retrieval. Build a better place to put knowledge, and learning will follow. That assumption, I think, is the one that needs examining.