The business case for removing a role explains what the role was for. It does not explain what the role was doing.
Those are two distinct documents. Only one of them has ever been written.
Every process has a declared output and a set of embedded functions. The output is what the process is named for: a map, a budget line, or a number someone reports monthly. That is what you are automating, and the case for automating it is usually sound. I want that clear up front, because what follows can be misread as caution.
The embedded functions are what the process was also doing for the organization while it produced that output. They are rarely documented anywhere. Process maps record named outputs and formal steps, not what happens around them.
So the output moves to a system, and the functions remain behind, unassigned. Nobody removes them. Nobody keeps them either.
Your savings are measured, but your deletions are not.
Five things a process carries besides its output
Take any recurring process a system could perform and ask what else it did while it ran.
Judgment. The person doing the work was learning what a normal result looks like. That is the same as learning to spot an abnormal one, and it happened for free as a side effect of the work, which is why nobody ever put a number on it.
Standards. Somewhere in that workflow, a more experienced person looked at the output and applied a threshold that was never written down. What separates acceptable from good in your firm lives in a handful of people’s heads, and it has been moving between them through the act of reviewing each other’s work.
Early warning. Manual steps are slow, and slowness has an underrated benefit. A person touching a transaction notices what does not fit and sees it on a different basis than a rule does. I have watched a system reject a customer’s request for an invoice adjustment based on rules that were each, on their own, correct. No rule could weigh the cost to the relationship, because that had never been a field. Take away the human touch, and those exceptions still exist. They surface further downstream, where they cost more and where nobody connects them back to an invoice.
Coordination. In most companies, much cross-functional alignment happens only because two teams must meet to complete a handoff. The handoff itself was never the valuable part. The unplanned conversation around it was frequently the valuable part.
I watch organizations automate the handoff from sales to operations, over and over. Lead times drop, and by one measure, customer satisfaction improves. What gets lost in the handoff is the two minutes when the salesperson passed along what the customer actually needed: the delivery window that mattered, the thing they had asked about twice. That comes back later as frustration, and nothing connects it to a conversation that stopped happening.
Validation. Someone looked at the number and formed a view about whether to trust it. That view is what turns data into something decisions can be made on, and it is not a property of the data.
None of the five will appear in your business case. All five are functions the organization relied on, and here is the structural point on which the rest of this rests.
A function does not disappear when you stop using it. It becomes unowned.
That is a different, worse condition. The organizational demand that function was satisfying is usually still there. The process met it. Now nothing does, and nothing is watching.
You can test this in your own company this week, without a project. Ask where exceptions surface now compared with three years ago, and whether the honest answer is that they are further downstream. Then ask your strongest mid-level person why a recent output was wrong, and listen for whether they can tell you it looked unusual but not what was actually wrong.
The old designs carried these on purpose
There is a fashionable argument that the old way was simply trial by fire, an accident of how work happened to be distributed, and that good riddance to it.
That reading is incomplete, so I do not accept it.
Apprenticeships, review gates, sign-off thresholds, rotational assignments, and structured exposure to more challenging cases under supervision. People who understood what they were doing designed these, and several were built specifically to carry out the functions above. They formed part of the developmental architecture through which most current leaders, including you, learned.
They were also slow and uneven, and whether you came out of them any good depended largely on who happened to sit above you. Both things are true at once. That is exactly why this is a design problem, not a debate.
So automate the declared output. You should. But find out what the old design was carrying before you take it apart, because some of those functions now have better instruments available than ever before, and some have no adequate substitute yet.
What the evidence supports, and what it does not
Instruction supplies concepts. Judgment develops when those concepts are tested through repeated decisions, feedback, and consequences. That depends on work being distributed so newer people handle a real portion of it, on somebody experienced seeing what they produced, on being wrong carrying a consequence, and on correction arriving while it still means something.
When routine cases disappear from a newer person’s work, the first of those cases goes with them. The development program does not. It continues, reporting participation to a leadership team that believes development is handled.
Two studies in respected journals point in opposite directions, and figuring out why is the most valuable hour a leadership team can spend on the subject.
Matthew Beane studied robotic surgery training for Administrative Science Quarterly. When the platforms removed the hands-on repetitions that training had always depended on, residents did not stop acquiring skills, but expertise production became selective, informal, and unreliable. Only a minority reached competence, and they did so through practices the institution had never sanctioned.
Brynjolfsson, Li, and Raymond studied the staggered rollout of a generative AI assistant among 5,172 customer support agents for the Quarterly Journal of Economics. Access to the tool raised resolutions per hour by about fifteen percent on average, and by thirty-six percent among the least skilled agents, with no significant gain at the top of the skill distribution. The detail worth sitting with is narrower than the headline: agents with two months of tenure and access to the tool performed about as well as agents with six months or more who did not have it. The authors suggest these systems may capture and disseminate the behaviors of the most productive agents.
Same category of technology. Opposite effects on how capability is built.
The difference is not the tool. In the surgical case, technology was installed in a training model built around repetitions it had just removed, and nobody redesigned the path a resident takes. In the support case, the tool sat within the work itself, carrying expert practice to people who did not yet have it. One workflow was designed around the technology. The other had technology dropped into it.
Lisanne Bainbridge explained why in a four-page paper in Automatica in 1983. The paper is often cited as a warning about automation. Read closely, it is a design argument. Automate the routine work, and you leave the operator responsible for exactly the abnormal situations automation cannot handle, while removing the practice that kept them capable of handling anything. The design erodes the competence it assumes. My own conclusion from her analysis, which goes further than what she wrote, is that the human role has to be designed on the same project plan and with the same authority as the machine role. Forty-three years later, that still rarely works.
At market scale, the pattern shows up in hiring. Stanford’s Digital Economy Lab found that by June 2026, employment among workers aged twenty-two to twenty-five in the most AI-exposed occupations was roughly nineteen percent below where it would have been if it had kept pace with less-exposed occupations, up from about fifteen percent a year earlier. The adjustment is running through hiring that does not happen, not through separations.
One note of honesty, covering all of it. The Stanford work is a descriptive analysis of payroll data rather than a causal estimate, and its authors say so. The two workplace studies are rigorous, and each describes a single setting. I read the pattern as directional, not conclusive. I would still bet my practice on it.
Why your dashboard will not tell you
Consider a composite. A mid-market firm automates first-pass analytical work in 2024. Turnaround drops by a third, the analyst tier shrinks through attrition, and senior staff stop correcting elementary errors. Three good years. In year four, two senior analysts leave in the same quarter, and the people who should be ready are not. They can tell you an answer looks unusual. They cannot tell you why. The firm hires externally, above band, and absorbs the ramp. The recruiting spend appears in the financials. What is left of the analyst tier appears nowhere.
Cost per unit falls. Throughput holds. Quality stays flat or improves because the people producing the work are the ones who already developed. The dashboard accurately reports health for years.
The reason is a measurement mismatch. Declared output is measured continuously as a flow. What accompanies it is not a single thing. Judgment and accumulated standards behave like capability stocks: they deplete quietly and show nothing until the day you need them. Coordination, validation, and early warning are control functions, and their absence tends to appear only under stress, usually elsewhere than where the change was made.
Neither kind has an advocate. Every named function in your company has someone who owns its budget and argues for it during the planning cycle. An unowned function has no one in the room when the agenda gets cut.
Then timing finishes the job. The removal happens this year, and the consequence lands when your current senior people retire or move on, often years later and frequently after the tenure of whoever approved it.
Picture the meeting. Someone is sitting across from a board, explaining why there is no internal candidate for a role that matters, because of a decision made during a budget review they have never heard of. If that person is your successor, you handed them a governance failure. If it is you, you will be explaining something you approved a decade earlier and never revisited, and there is no good answer for why nobody was watching.
Three ways to get this wrong
Automate the declared output and never inventory anything else the process was carrying. Most of the market is here.
Or sense the risk and slow down, keeping manual work a system should be doing because you believe it develops people. That company loses twice. Its people build skills the market no longer pays for, and a competitor that figured out how to do both takes the business.
Or adopt hard, see real gains, then find your people cannot function without the tool because nobody built the judgment that lets a person recognize when the output is wrong. The tool gets blamed for a design failure.
All three are component decisions made within a system that has no owner.
The Embedded Function Audit
Four steps. It is a single redesign rather than a list of initiatives, and it belongs above any single function because no single function can complete it.
Inventory what the process carries. Before you remove the declared output, ask what else moves through the process. Most leadership teams have never made this list, and a focused cross-functional session will usually produce a first version.
For each one, ask what demand it was meeting. This step changes the conversation. A process can disappear. The organizational demand it was satisfying usually does not. Human review goes away, and the demand for validation remains. The handoff goes away, and the demand for coordination remains. Onboarding moves to system-generated modules, and the demand for someone to confirm that the new hire actually has what they need and can do what they said in the interview remains. Junior analytical work goes away, and the demand for people who can eventually replace your senior bench remains, sitting unaddressed for about eight years.
Then decide which of those demands still serve the organization’s purpose. Not every embedded function deserves to survive. Some met a demand that no longer exists, some compensated for a design flaw you have since fixed, and some were overhead the old process made invisible. This is the step people skip because letting something go takes more conviction than keeping it, and it is the step that keeps the audit from becoming preservation by another name.
Assign the survivors to whatever carries them best now. Some of the technology handles them better than the old design ever did. Repetition and exposure are the clearest examples. The traditional path took years to put a hundred cases in front of someone and exercised no control over which hundred. A designed process compresses that and selects them, including exceptions a person would otherwise meet only by luck.
Others still require a person. Real accountability cannot be fully simulated, though simulation can accelerate practice. Some evaluative standards remain partly tacit and require supervised interpretation in context.
I do not always know where that line sits in a given firm until we have reviewed the actual work. It moves. Two years ago, I would have insisted that a seasoned employee produce the first reorder proposal from the demand signal. Now I would let the system carry that weight and keep the final call with the person, because the call was always the judgment and the arithmetic behind it never was.
What has not changed is that someone has to draw the line deliberately. Leave the split implicit, and the technology will take everything it can, leaving the human with a signature.
The four steps reveal something that surprises people: automation creates work as much as it removes it. Designing and testing the system’s logic, owning the data that feeds it, handling the cases it refuses, and turning its output into something a client can use. In many companies, those are nobody’s job, absorbed by whoever has capacity, which means they develop no one either. A role that disappears should evolve, and somebody has to own that sentence, or it won’t happen.
Then measure readiness rather than headcount. How many people could do this job in five years, and what are they doing right now?
The part that is not in the business case
Someone is involved in this decision, and none of the analysis includes them.
Somewhere in your organization, a twenty-six-year-old is about to be replaced by a system, sitting in a development program that still exists, learning less than the org chart claims. Nobody failed them. They removed the embedded half of their job along with the declared half, and no one was assigned to notice.
Run that arrangement for a decade, and you get an organization that cannot fill its own senior roles and does not know why, having paid for a development program the entire time. I am not predicting that. It is what the current design is capable of producing, and it will keep producing it until someone changes the design.
That is why I keep saying your people are the reason for the technology decision, not the residue left over after it. There is nothing sentimental about that. Several of these functions still have no adequate substitute, and somebody has to carry them.
One requirement, before the next approval
None of this is really about automation. Automation is the version of it happening in your company this year. The same thing happens when work moves to a shared service center, when two companies merge, when a system is replaced, or when one person retires after thirty years. A component changes, and the rest of the system remains designed for the component that left.
So make this a condition of approval, not a question you remember to ask.
No proposal to automate, outsource, or eliminate a process reaches your desk without specifying the functions the process currently performs, which of them still serve the organization, and who owns each one afterward.
A governance change, not a program. It costs nothing and puts the question in front of the only people who can answer it.
The first few proposals will come back thin. That is the finding, not a setback. Nobody has been asked for this before, which is exactly why the functions went unowned in the first place.
You are not late for this. You are early, and the tools for rebuilding what you remove are better than anything the original designers had to work with. But none of it is automatic, and no report will prompt you.
Someone has to ask what else the work was doing. In your organization, that is you.
Frequently asked questions
Is this an argument against automation?
No. Most automation cases are incomplete rather than wrong. They price the declared output accurately but never inventory the embedded functions, making it a scoping failure rather than a technology failure. Customer support evidence clearly shows that the technology can build capability, particularly among less experienced workers, when the workflow is designed around it.
Isn’t moving slowly the safer choice?
No, and it fails about as often. A company that preserves manual work to develop people ends up with people building skills the market no longer pays for, a heavier cost structure, and an exit problem when its best juniors leave. Both errors treat the tool as the decision.
How is this different from tacit knowledge?
Tacit knowledge is what a person holds. An embedded function is what a process performs for the organization. The distinction matters because it changes who owns the problem. Tacit knowledge sounds like a talent issue and gets handed to HR. An embedded function is a property of the operating model, so it belongs with the people who design and approve processes.
Doesn’t this mean preserving work that should go away?
It should not, and the third step of the audit prevents it. Some embedded functions met a demand that no longer exists or compensated for a design flaw you have since fixed. Those should be allowed to end. The question is never whether to keep the old work. It is which demands the organization still has and what will meet them.
How would we know this is already happening to us?
Look for a gap between output quality and bench readiness. If the work product is strong but you would struggle to name internal successors for critical roles, a capability stock is depleting even though the flow looks healthy. Two further signs: mid-level people who can tell an output is unusual but cannot diagnose why, and exceptions that used to surface early now surface downstream at higher cost.
Let’s talk
If you are automating processes or reducing roles, there is one question to answer before the decision is final. What else was that work carrying, and who owns it now?
I work directly with CEOs, COOs, and CHROs on that question: what your processes actually carry, which functions have quietly lost their owner, and how to make the technology and capability decisions as one decision instead of two.
Every engagement begins with a complimentary 45- to 60-minute conversation. No preparation, no pitch deck, nothing leaves the room.
Book a Confidential Consultation →
Sources
Bainbridge, L. (1983). Ironies of automation. Automatica, 19(6), 775–779. https://doi.org/10.1016/0005-1098(83)90046-8
Beane, M. (2019). Shadow learning: Building robotic surgical skill when approved means fail. Administrative Science Quarterly, 64(1), 87–123. https://doi.org/10.1177/0001839217751692
Brynjolfsson, E., Chandar, B., & Chen, R. (2026). Canaries in the coal mine? Six facts about the recent employment effects of artificial intelligence. Stanford Digital Economy Lab. https://digitaleconomy.stanford.edu/publication/canaries-in-the-coal-mine-six-facts-about-the-recent-employment-effects-of-artificial-intelligence/
Brynjolfsson, E., Li, D., & Raymond, L. (2025). Generative AI at work. The Quarterly Journal of Economics, 140(2), 889–942. https://doi.org/10.1093/qje/qjae044