The consulting story I would tell when a business owner says, “I can't lose her. She knows everything.” A business owner tells me: “I have one employee I cannot lose. She knows everything.” I know what they mean.
They mean it as praise. And it probably is praise. But I hear a second sentence underneath it: We have a single point of failure.
The employee knows which customer needs what. She remembers which vendor responds to text instead of email. She knows which spreadsheet contains the real number. She fixes the report before anybody sees it.
She remembers who has not paid. She knows which process in the manual is wrong. She knows the weird exception. She knows what happened last Tuesday.
Everybody asks her. She is indispensable. Wonderful employee. Terrible architecture.
THE HUMAN API
I started thinking of this as the human API problem. In software, an API lets one system communicate with another. In a badly connected business, a human often becomes that interface. Open System A.
Find the answer. Translate it. Copy it into System B. Remember that Customer C has an exception.
Tell Person D. Follow up with Vendor E. Fix the formatting. Explain why the dashboard is wrong.
Now the systems technically exist. The human is what makes them function together. Organizations celebrate this employee. Sometimes they promote them.
Sometimes they give them more work because they are so reliable. Then the employee goes on vacation and the company discovers it did not have an operating system. It had Jennifer.
I HAVE BEEN JENNIFER
I understand the attraction because I have been the person people called. There is a genuine reward in being able to solve the weird thing. Somebody sends a tiny message. A building name.
A strange condition. A fragment of an exception. And because I already have the environment loaded in my head, the rest appears. Door topology.
CPT. Yard. Equipment. Historical throughput.
Likely failure modes. Expected flow. The person sent six words. My brain received a pointer into years of operating context.
That is expertise. It is useful. It is also very difficult to scale if the system depends on the expert being awake.
THE GOAL IS NOT TO MAKE THE EXPERT LESS VALUABLE
This is where business owners get nervous. If we document what Jennifer knows, automate what Jennifer does, and build better interfaces, are we making Jennifer less valuable? No. We are trying to stop wasting Jennifer.
If an expert spends twenty minutes every morning copying the same information, we are paying expert wages for clerical transport. If everybody interrupts her for the same routine answer, expertise is being consumed by repetition. If she manually assembles a report from information the systems already know, her judgment is not what we are purchasing. We are purchasing her ability to copy.
That is a terrible use of a great employee.
AUTOMATION SHOULD REMOVE CLERICAL GRAVITY
This is the kind of automation I like. Not: How many humans can we eliminate? But:
What work is consuming human attention even though the machine could carry it reliably? Searching. Copying. Reformatting.
Remembering routine deadlines. Generating repetitive reports. Surfacing an exception. Routing a standard request.
Recording state. Those are good automation candidates. Then the human keeps the work that benefits from being human. Interpret.
Coach. Negotiate. Decide. Escalate.
Help. Notice. That is a much more useful partnership.
THE APP FOR ONE PERSON
I learned an important version of this lesson building a small app around one employee who could not read. The work itself did not necessarily require the kind of reading the interface expected. So the interface was creating artificial labor. The design problem became:
What is essential? What state does this person need? What is the next correct action? What can be removed?
How can we present the work around the person instead of presenting the database architecture and asking the person to become compatible with it? That question made the software better. And the principle later scaled. The person should not have to navigate five fragmented systems to perform one coherent job.
Bring useful state together. Reduce translation. Make current state obvious. Present the next useful action.
Let the human spend attention on the work.
THE BEST EMPLOYEES SHOULD NOT BE MIDDLEWARE
This is the consulting sentence I would put on the whiteboard. Your best employees should not be middleware. If the systems do not connect, good employees connect them manually. They remember.
Translate. Copy. Chase. Reconcile.
That makes them look indispensable. Sometimes indispensability is evidence of system debt. It is a compliment to the person and an indictment of the architecture. The business should preserve the person's expertise while removing the unnecessary integration burden.
START WITH A WEEK OF QUESTIONS
I would not begin by buying software. I would begin by following Jennifer for a week. What questions does she answer repeatedly? What information does she copy?
What does she remember that exists nowhere else? What errors does she quietly correct? What report does she manually reconcile? Which customer exceptions are stored only in her head?
Which tasks require judgment? Which tasks are pure repetition? Which pieces of information have an authoritative source? Where do systems disagree?
What happens when she is absent? That gives us a map. Then we can separate three things. Knowledge.
Workflow. Judgment. Those are different.
KNOWLEDGE SHOULD BE FINDABLE
Some of what Jennifer knows is company knowledge. Hours. Policies. Vendor instructions.
Customer history. Service rules. Standard operating procedures. That information should have a home.
It should be current. Searchable. Owned. Versioned where appropriate.
The business should not require a séance when the expert is unavailable.
WORKFLOW SHOULD LEAVE STATE
Some of what Jennifer does is workflow. Lead came in. Quote sent. Waiting for approval.
Scheduled. In progress. Blocked. Completed.
Invoice sent. Paid. Follow-up due. Those states should exist somewhere other than memory.
Once they do, the business can route normal work without Jennifer manually chasing every transition.
JUDGMENT SHOULD STAY HUMAN
Some of what Jennifer does is actual expertise. The customer's request is unusual. The vendor relationship is delicate. The normal path does not fit.
The information conflicts. A decision has consequences. That is where I want Jennifer. Do not automate the expert decision just because we successfully automated the reminder.
The point is not automation maximalism. The point is human attention. Spend it where it creates value.
THE CONTROL ROOM VERSION
This thinking eventually became part of my Control Room philosophy. A manager should not stare at everything equally. Normal work should move. Exceptions should surface.
The interface should tell you: What is active? What is complete? What is delayed?
Who needs help? What documentation is missing? What changed? What has to be ready next?
That is how we stop using the expert as a walking query engine. The system should answer routine state questions. The expert should answer the weird one.
REPORTING IS THE SAME PROBLEM
Quarterly reporting is another place the human API appears. The company already observed the work. Then a manager reconstructs it. Again.
Again. Again. If the data already exists, generate the baseline. Let the human explain why it matters.
The report should not require a person to become the ETL pipeline. That is not leadership. It is clerical gravity.
THE FEAR OF DOCUMENTING YOURSELF OUT OF A JOB
Employees can resist this kind of improvement for a rational reason. They may believe that if they teach the company everything they know, they become replaceable. That fear deserves respect. The way leadership frames the project matters.
We are not extracting your brain so we can eliminate you. We are eliminating the stupid work that prevents you from using your brain. We want the business to stop failing when you take vacation. We want your expertise available for harder problems.
We want you teaching. Improving. Handling exceptions. Becoming more valuable.
That is a better conversation.
MAKE THE EXPERT A MULTIPLIER
The ideal outcome is not that everybody becomes Jennifer. It is that Jennifer's repeatable knowledge becomes infrastructure and Jennifer herself moves toward higher-leverage work. Maybe she becomes the person who owns process quality. Maybe she trains.
Maybe she handles complex customers. Maybe she improves the system. Maybe she becomes the person who notices the next thing worth automating. That is how capability compounds.
The expert stops being the bottleneck and becomes the multiplier.
A BUSINESS SHOULD SURVIVE VACATION
I use a very simple test. Can the expert take a week off? Not “can somebody eventually figure it out after three days of panic?” Can the operation continue?
Can people find current information? Can they see state? Can normal workflows move? Can exceptions be routed?
Can someone understand what happened yesterday? Can Jennifer return without spending two days reconstructing what everybody did to the system? If not, we have work to do.
THE PART I WOULD NOT AUTOMATE
There is a line I would protect. I do not want a business that feels like a vending machine because we got excited about workflow automation. Relationships matter. Customers sometimes need somebody to hear what they are actually saying.
Employees need coaching. Exceptions need judgment. Trust is built by humans. The best operating system makes room for those interactions by removing the repetitive noise around them.
That is why automation does not have to threaten the operator. Done well, it can protect the operator from being consumed by everything beneath their actual skill level.
WHAT I WOULD TELL THE OWNER
So when you tell me: “I cannot lose her. She knows everything,” I am not going to tell you to replace her. I am going to tell you to honor what that sentence means.
She has accumulated enough operational knowledge to become infrastructure. Now let's build infrastructure around her knowledge so she does not have to personally impersonate it forever. Follow her work. Capture repeatable knowledge.
Make workflow state visible. Automate routine transitions. Surface exceptions. Preserve judgment.
Train other people. Then give your best employee harder, more interesting work. Your goal is not to make Jennifer unnecessary. Your goal is to make it unnecessary for Jennifer to remember that Bob's invoice is still sitting in column G because the CRM and accounting system refuse to talk to each other.
Jennifer has better things to do.
THE SUCCESSION PLAN IS A SYSTEMS TEST
This also turns succession planning into something practical. Do not begin with, “Who could replace Jennifer?” Begin with, “What does Jennifer actually carry?” Some of it belongs in documentation.
Some in software. Some in training. Some in relationships. Some in judgment that only develops through experience.
Now the organization can build layers. Document the repeatable facts. Expose workflow state. Cross-train routine decisions.
Create an escalation path. Pair another person with complex work. Preserve the historical context behind recurring exceptions. That is much stronger than waiting until the expert gives notice and asking them to write everything down in two weeks.
Expertise is not a document you can dump at the end. It is a model built from relationships, exceptions, timing and history. A good system captures pieces of that model continuously.
THE BEST AUTOMATION FEELS LIKE RELIEF
I know an automation is good when the operator's reaction is not fear. It is: Oh thank God, I never have to do that again. That is the target.
The stupid reconciliation. The recurring reminder. The status copy. The report assembly.
The duplicated entry. The hunt for the right version. Remove that. Then ask the operator what they would do with the recovered attention.
Usually the answer is not “nothing.” They already know where the next valuable problem is. Good employees almost always do.
THE CONSULTING ANSWER IN ONE SENTENCE
Do not automate your best employee out of the company. Automate the repetitive integration work out of your best employee's day, preserve the expertise, make normal state visible, and let that person spend their time where human judgment actually earns its keep.
WHAT EXPERIENCE CHANGES
The longer I work with systems, the less interested I become in impressive-looking complexity. I want the relationship to be clear. I want the state to be knowable. I want the human to understand the next useful action.
I want the exception to have somewhere to go. I want the evidence to survive the person who created it. And I want success in one place to avoid quietly creating failure somewhere else. Those preferences are not theory to me. They are what remained after years of watching real systems answer back.
That is why I keep telling the stories. The story carries the mechanism. The mechanism is the part somebody else can use.
THE FIRST AUTOMATION I WOULD BUILD FOR JENNIFER
I would ask one question: What do you hate doing twice? Not what could AI do. Not what software platform should we buy.
What do you hate doing twice? The answer may be embarrassingly small. Copying a customer's address into three places. Sending the same preparation note.
Rebuilding the same weekly status list. Checking whether somebody replied. Renaming the same kind of file. Searching for the same policy.
Good. Start there. Map the input. Map the output.
Identify the authoritative source. Identify the exception. Automate the boring path. Then measure whether Jennifer actually got time back.
That is a real automation win. Ten minutes recovered every day is over forty hours in a working year. Now find the next one. Small operational improvements compound because human attention is reusable.
THE COMPANY SHOULD KNOW WHAT IT KNOWS
There is a larger philosophical point hiding here. A company can possess information without being able to use it. The policy is in a document. The customer history is in email.
The status is in a spreadsheet. The exception is in Jennifer's head. The invoice is in accounting. Technically, the organization knows everything.
Practically, no one can answer a question without assembling the company by hand. That is not knowledge. That is scattered evidence. A good business system turns scattered evidence into accessible operating state.
Not one giant database containing the universe. Enough connection that the next person can act without rebuilding context from scratch. That is what I mean when I say the company should survive vacation. It should know what it knows even when its favorite human API is at the beach.
WHEN JENNIFER TEACHES THE SYSTEM, SHE SHOULD GET CREDIT FOR BUILDING IT
There is one cultural detail I would care about enormously. If we convert Jennifer's operating knowledge into documentation, training and software, that contribution should not become invisible. She helped build the system. Say so.
People are far more willing to share expertise when the organization treats knowledge transfer as leadership rather than extraction. The person who teaches the company how the work really functions is creating durable capacity. That is an accomplishment. Recognize it.
Then make the next role bigger. The worst possible outcome is to take everything the expert learned through years of experience, convert it into company infrastructure, and act as though the software somehow invented the knowledge. It did not. The human taught the system.
That story should remain attached to the improvement.