You Have to Let Go the Only Person Who Knows How

The decision is already made in your head. You have to fire an employee who is the only one who knows the job, and every version of the plan ends with the same hole where a working process used to be. Do it in this order: capture the work first, while the person still has a reason to answer questions, then verify what they personally own, then act. The order is the entire job, because after the conversation you will never get another honest walkthrough.

How Do You Fire Someone Who Is the Only One Who Knows the Job?

You capture first, and you act second. That is the whole answer, and almost nobody does it in that order, because the decision feels urgent and the documentation feels like a project you will get to.

Treat the person as a load-bearing wall. You do not knock one out and then go find out what it was holding up. You put the temporary supports in place, you confirm what carries the weight, and only then do you swing.

Owners skip that step because they have lived with this bottleneck so long it has stopped registering as a risk. It is worth understanding why your best person ends up holding it all before you decide the problem is the person.

Nothing about the termination changes until the highest-risk process this person runs exists somewhere outside their head.

That is not a delay tactic. It is a sequence, and it usually costs two to four weeks.

Capture Before You Act, Never After

The day you tell someone they are done, the price of everything they know goes up and their willingness to explain it goes to zero. Even a decent person who takes the news well stops volunteering the small things: the exception they handle every third Tuesday, the client who has to be called before the invoice goes out, the workaround for the field that never saves.

The moment you say the words, you stop being someone they teach and start being someone they negotiate with.

One financial planning principal put the underlying dynamic more bluntly than any consultant would: people control stuff because they do not want to give it up. That is true when the news is good. It is much truer when the news is that they are leaving.

So run capture while the relationship is still ordinary. Recorded working sessions, in the normal rhythm of the week, framed as documentation the whole company is doing. This is not deception, it is sequencing, and if it feels uncomfortable, notice that you already run this exact drill in reverse every time a key person calls in sick and you spend the day discovering what actually breaks without them.

What Can You Realistically Get in Two Weeks?

Less than you want and more than you think. Two weeks of focused capture gets you the two or three processes that would hurt most, documented well enough for a competent replacement to run them badly at first and correctly by month two. It does not get you a library.

That honest scope is the same one we use for an emergency knowledge rescue when a key employee resigns, and it is worth stating plainly before you start: two weeks buys a starting point, not a finish line.

Here is the shape of it.

1. Rank by damage, not title. List what this person touches, then ask what breaks first, how fast, and who calls you when it does. The top three go on the calendar. Everything else waits.
2. Book recorded sessions, not write-ups. Nobody being managed out is going to write a manual. They will, however, do their job on a screen share for an hour. Plan on two to four hours per process.
3. Capture purpose, decisions, and steps. Why the process exists, where a judgment call happens and what the right call looks like, then the click-by-click. The middle one is the part that walks out the door with people.
4. Have someone else run it back. Not read it. Run it, live, with the source watching. Anything that stalls is a gap, and gaps found now are cheap.

Notice that none of those steps is writing. Documentation is the output, not the activity, and every hour spent on a template is an hour not spent recording the person who is about to leave.

Check What They Personally Own

Before anyone is told anything, find out what is in this person's name rather than the company's. This is the step that gets skipped, and it is the one that produces the ugliest surprises.

At one staffing firm, a departing employee personally owned the company's video hosting account. Every training video the business had made sat behind a login that belonged to him, and ownership had to be transferred before he went dark. At a real estate investment company, an employee had recorded a training video with social security numbers and credit reports visible on screen, and the whole thing had to be blurred before anyone could use it. Neither of those problems is solvable after the last day.

So audit the accounts, the vendor portals, the phone numbers that ring to a personal cell, the shared drives with one owner, and the recordings that may contain things you cannot legally circulate. A full pass belongs on the offboarding checklist that protects the business, but for this situation you need it done early and quietly, because every transfer request you send after the conversation is a request the other party has no reason to approve.

Grade on Countable Behavior While You Decide

If you have not made the call yet, the trap is judging on feel. A staffing agency's customer service trainer had two representatives on the chopping block, both below the 76 percent attainment bar and two percentage points apart from each other.

One was systematic and hit her volume but never acknowledged what the caller had just said. The other applied coaching on the very next call and still sounded robotic doing it. On paper, both were following instructions.

His fix was not to argue about tone. He moved the grading to things that cannot be debated: call avoidance and schedule adherence. He also reworded a rubric item from "show empathy or enthusiasm when needed" to "empathy or enthusiasm statement," because he wanted his graders hunting for one specific, findable sentence in the first thirty seconds rather than forming an impression.

If you cannot name the countable behavior you are firing someone for, you are not ready to fire them, and you are definitely not ready to defend it.

That reframing also tells you something about the capture plan. Countable standards are transferable. Impressions are not, and a role built entirely on one person's instincts is a role you will have to rebuild rather than refill.

---

The Day You Tell Them, and the Day After

Have the transfers done first. Account ownership moved, recordings in your library, the top processes captured and test-driven by someone else. Then hold the conversation, keep it short, and be specific about the countable thing rather than the feeling.

Expect the temperature to change immediately. Access removal should follow a written order that you wrote last week, not one you improvise in the hallway. Assume any promise of a clean handover in the final two weeks will be partial, and that the promise made warmly on day one thins out by day four.

The day after is the real test, and it is almost always quieter than owners fear. What goes wrong is rarely dramatic. It is the third-party portal nobody could log into, the report that stops arriving, the recurring task that existed only as a repeating reminder on somebody's phone.

How Do You Make Sure You Are Never Here Again?

You stop letting any single role become a load-bearing wall you cannot inspect. That starts with knowing who holds what and how replaceable each of them is, which is the point of scoring your single points of failure rather than guessing at them.

Then you make capture continuous instead of reactive. When documentation only happens at resignations and terminations, it is always emergency work at the worst possible price, which is why a standing knowledge transfer plan beats an emergency one every time. The Systems Effect exists mostly because owners call after the decision is made, and the honest version of that work is triage: capture the highest-risk knowledge intensively and produce something usable before the person leaves.

Do one thing this week, whether or not you have a termination coming. Pick the person whose absence would hurt most, book one hour, and record them running their single most important process while the relationship is still perfectly normal.

Frequently Asked Questions

How do you fire an employee who is the only one who knows the job?

Capture before you act. Spend two to four weeks running recorded working sessions on the two or three processes that would hurt most if they vanished, have someone else run each one back live, and transfer any accounts or assets registered in that person's name. Then hold the conversation. Firing first and asking for a handover second is how businesses lose the process along with the person.

Should you run knowledge transfer before or after telling someone?

Before, without exception. Once someone knows they are leaving, cooperation becomes a negotiation, and the small unwritten details are exactly what stops flowing first. People hold on to what they know when it is the only leverage they have. Capture done inside a normal working week gets you the exceptions and judgment calls that a formal handover never surfaces.

What do you check before terminating a key employee?

Anything in their personal name rather than the company's: software and video hosting accounts, vendor portals, domain and phone numbers, shared drives with a single owner. One departing employee personally owned his company's entire video hosting account, and ownership had to move before he went dark. Also review existing recordings for sensitive data on screen, because material with customer information visible cannot be reused until it is edited.

How long does emergency knowledge capture take?

Two weeks of focused effort gets the highest-risk processes documented well enough for a replacement to run them, at roughly two to four hours of the expert's time per process. It does not produce a complete library, and it should not be sold to yourself as one. Rank by damage, capture purpose, decision points and steps, and accept that you are buying a starting point rather than a finished system.