You Didn't Lose Institutional Knowledge. You Chose Not to Document It.

If the backup can't run the process, I don't care how many procedure documents you have.

The employee leaves. The report stops. Nobody understands the account structure. A customer exception turns into an emergency because the only person who knew why it existed isn't answering the phone anymore.

Management announces that the company has lost institutional knowledge.

I want to know what the institution did to retain it while the employee was still there.

Did you allocate time? Assign an owner? Maintain access? Train a backup? Test whether anybody else could perform the work? Federal continuity guidance identifies usable vital records, trained continuity personnel, defined responsibilities, and regularly updated materials as parts of maintaining essential operations through disruption. [1][2]

Or did you keep sending everything to the same person because that was faster, then act surprised when the dependence became inconvenient?

Don't sell me a fucking tragedy before we've examined the management decisions.

I'm going to follow the dependency

When I evaluate a business, I want to understand how the work connects. The website, advertising account, intake process, customer records, sales reporting, billing, and service delivery are parts of an operation. A failure at one handoff can change the economics of everything downstream.

That's why “we have the login” isn't a sufficient answer.

Who controls recovery? Where are the source files? Who can authorize changes? What does the report include? Which records does it exclude? Why? What breaks if someone changes a field that looks redundant?

Ownership has to become usable control. A company account that only an unavailable contractor can recover is a dependency. A company report that nobody can explain is a dependency. A procedure that requires the author to interpret every paragraph is a dependency wearing a document title.

I want those dependencies identified before somebody resigns, gets sick, takes leave, or simply stops rescuing everyone after hours.

The employee having a life isn't the operational failure.

A shared drive doesn't prove a damn thing

Show me the procedure everyone claims exists.

Is it current? Does it say what outcome the process serves? Does it identify the required information, the handoffs, the approvals, and the circumstances under which the normal steps should stop?

Can the next qualified person find it and use it?

I don't need a recording of every mouse movement. I need enough context to understand why the process works, where it can fail, and who can decide what happens when the instructions no longer fit.

Imagine a high-ticket local service business with a pricing exception for a repeat customer. A note saying “use special price” preserves almost nothing useful.

Who approved it? What service does it cover? Does it expire? Does it depend on volume, payment timing, or a limited scope? Who must approve an extension?

Without that context, the next employee might either deny a legitimate arrangement or keep offering terms the business never intended to make permanent.

That example is hypothetical. The operating question is straightforward: did you preserve the decision, or only the instruction somebody remembers following?

Stop rewarding the fire and neglecting the fire prevention

Suppose the person who fixes every emergency gets praise, access, and attention. The person who asks for time to document the cause gets told to clear the customer backlog first.

What behavior is the company buying?

Then management asks the emergency fixer to train a backup while keeping the same output targets and handling the same interruptions.

Where, exactly, is the training supposed to fit?

If you want less dependence, you may have to accept a temporary reduction in visible production. The experienced person needs time to explain. The backup needs time to try, misunderstand, ask questions, and try again.

That's work. Put it in the budget and the schedule.

You don't get organizational capability by announcing that everyone should be more organized while refusing to pay for the time organization takes.

Price the interruption before you dismiss the investment

Here's an invented financial example, not a turnover benchmark.

An employee earning $110,000 leaves. Assume four months of vacancy and ramp-up create an estimated $20,000 per month in lost contribution after accounting for variable costs the business avoids while that output is not produced. Assume another $25,000 in incremental recruitment and outside support.

That's $105,000 of modeled exposure: $80,000 plus $25,000.

It is not automatically the net cost of the departure. Account for salary and benefit savings, replacement costs, and other relevant changes. Don't count outside support twice if it already reduced the output-loss estimate. Don't call delayed work permanently lost revenue without evidence.

The point is to compare complete alternatives.

What would cross-training, better access controls, and tested documentation cost? How much disruption would they realistically prevent? Could an outside provider restore capability quickly enough? Does this process matter enough to justify redundancy?

I don't prescribe a documentation project because documentation sounds responsible. I want to understand the exposure and the price of reducing it.

If the process is disposable, cheap to reconstruct, and low consequence, say so. Spend accordingly.

But make that choice while you still have options. Don't wait for the failure and tell me nobody could have anticipated that one person might eventually leave.

Preserving the business doesn't entitle you to own someone's brain

An employee brings judgment, skill, and experience. A business can't turn all of that into a manual, and it shouldn't pretend a handover makes the employee interchangeable.

What I expect is a workable record of the company's processes, decisions, access arrangements, and responsibilities within the employee's role.

Some judgment will remain personal. That is a reason to develop capable people and maintain appropriate backup, rather than assume a sufficiently large folder can replace expertise.

Confidentiality still matters. Documenting internal information does not mean circulating it to everybody. Give people the access needed for their responsibilities. Keep credentials in approved credential systems. Keep customer and company information in approved places with appropriate restrictions.

I won't publish someone else's operating details to prove I understand operations. I apply the same principle inside the organization: preserving knowledge and distributing it indiscriminately are different decisions.

AI can draft the instructions. Someone has to run them

AI can help turn an explanation into a first draft or expose gaps in a procedure. Its usefulness depends on the tool, the source material, and the review.

A polished document can still omit the step that keeps a routine change from breaking billing.

Have the operator review it. Have a qualified backup use it in a controlled test. Check the output with the person or department receiving the work. Correct the document when reality contradicts it.

Use only information the business has authorized for that tool. Moving a confidential mess into an unauthorized system doesn't become sensible because you called it knowledge management.

And assign a person to maintain the result. AI isn't the process owner. The folder isn't the process owner. “The team” needs a named person with authority to keep this current.

Test the claim while the expert is available

Let the backup run a normal cycle. Can they locate the inputs, obtain access, produce the result, recognize an exception, and explain when they need approval?

If they can't, you've found something useful. Fix it. Don't punish the test for revealing the fucking problem.

Deliberate concealment can be an employee issue. A person can withhold required information or violate a sound handover process. Investigate that when the evidence supports it.

But if you never funded documentation, never clarified ownership, and never tested continuity, you haven't established sabotage. You've established a business that kept choosing convenience over resilience.

Some knowledge will always leave with a person. The question is how much of the company's ability to operate you knowingly allowed to depend on them.

Before you tell me what walked out the door, show me what you chose to preserve.

Continue Reading on anuhlest

• Your CMS Publishes the Promise. Your CRM Has to Help the Business Keep It. — why systems, governance, adoption, and usable information have to support the same operation.
• You Hired Someone. Now What the Fuck? — why management must define the work, authority, dependencies, and continuing need before assigning the role.
• Everybody Is Responsible. Nobody Is Accountable. — why shared involvement without named authority creates operational ambiguity.