Critical-Knowledge Systems Should Support People, Not Replace Them

When an expert leaves, an organization often discovers that it had been treating a relationship as a role and a practical repertoire as a job description. The person may have held deep domain expertise, but the harder loss is usually the way they applied familiar approaches to a particular context, transforming the standard method while keeping the result recognizable to colleagues and clients—what the source calls an expert who “plays hot.”

Critical knowledge includes the expertise of people who “play hot,” transforming standard approaches through innovative application rather than merely repeating a documented method. A system could analyze documented expert work, assess whether critical knowledge is concentrated, classify the knowledge type, estimate succession risk, and recommend a transfer mechanism matched to the expertise.

I can see real value in that support function, but I would not mistake it for a succession decision. A system can put the vulnerability on the table; people still have to decide what the relationship, the learner, and the work require.

Risk can be surfaced before departure

Departure-impact simulations can show what disappears when critical knowledge leaves. Concrete cost and capability assessments can justify transfer investments. These functions address a common problem: organizations recognize a vulnerability only after the person has already left or become unavailable.

A system can make concentration visible. It can connect expert work to documents, projects, and capabilities. It can ask whether a body of knowledge is largely explicit and can be documented, or whether it is tacit and requires apprenticeship or another relationship-based transfer. It can track whether a transfer effort appears to be moving knowledge rather than merely producing activity.

Those are significant contributions because they create a record for a conversation that is otherwise postponed. A vulnerability score, however, is only a signal. It does not know whether an expert wants to teach, whether an apprentice has the right access and time, whether a community can absorb the work, or whether a particular departure would change a team in ways the documented evidence cannot predict.

Match the mechanism to the knowledge

Tacit knowledge may require apprenticeship, while explicit knowledge may support documentation. The distinction should guide the transfer plan. A documented technical procedure may be made more discoverable, reviewed for completeness, and taught through training. A practical judgment developed through difficult cases may need observation, repeated work alongside the expert, discussion of exceptions, and time for a learner to make and correct their own decisions.

Many transfer plans fail because they apply one mechanism to every kind of expertise. The expert writes notes, the notes are stored, the plan is marked complete, and nothing has established that another person can recognize the relevant situation or act with the necessary judgment. The completion record survives beautifully; the knowledge, less so.

Transfer-effectiveness tracking can help expose this failure. It should ask whether an apprenticeship, documentation effort, or training practice changed someone’s actual capability. The answer may remain partial, and that uncertainty should be recorded rather than hidden behind completion counts.

Relationships remain the work

Humans remain responsible for maintaining expert relationships and executing transfers. This boundary is exact. Automation can assist with risk assessment, strategy recommendation, impact simulation, and the discovery of organizational dependencies. It cannot maintain the trust, attention, and willingness that make a transfer possible.

An expert cannot be reduced to a resource node whose knowledge is extracted on command, and a learner is not a destination field waiting to receive it. The transfer may require room in a schedule, access to real work, permission to ask basic questions, and recognition that the expert’s practice includes context no system can fully infer from documentation.

The strongest critical-knowledge system therefore makes a careful division of labor. It notices concentration before a crisis. It identifies possible loss and proposes a method suited to the knowledge at hand. It records whether the chosen transfer appears to work. Then it returns the consequential decisions to the people who must build and sustain the relationship.

This division of labor is what makes the system’s evidence useful. A vulnerability score can start the conversation and help justify the time or cost of a transfer, but it cannot conduct the apprenticeship, preserve the expert relationship, or decide when a new practitioner has truly learned how to carry the work forward. I would rather have the system expose that uncertainty than hide it behind a very precise completion percentage.