Automation Without Empathy
There's a peculiar irony in being displaced by the very systems you helped build.
For four and a half years, my job was to make other jobs unnecessary. I was a part of a team that built robotic process automation tools—digital systems that could perform repetitive business tasks faster, more accurately, and more cheaply than human workers. Data entry, status updates, routine communications—all automated, all optimized, all "improved."
I was good at it. The work was technically interesting, the impact was measurable, and the value proposition was clear. Automation saved the company money. It freed people from tedious work. It reduced errors. Everyone benefited.
That was the story, anyway.
The truth was more complicated. Yes, automation reduced headcount in certain areas. But the people whose jobs were eliminated rarely "moved up" to more strategic work, as the consulting presentations always promised. They were let go, or reassigned to other repetitive tasks, or quietly pressured to find positions elsewhere. The efficiency gains were real. The human cost was also real. And those of us building the tools weren't supposed to think too hard about the second part.
Until April 30, 2024, when I learned that automation doesn't stop at factory floors or back-office operations. Eventually, it comes for its builders.
The Builders Become the Built-Out
The RPA Center of Excellence was successful by every metric that mattered to senior leadership. We had automated dozens of processes, saved thousands of hours, and reduced operational costs by millions of dollars. Our bots ran reliably, our error rates were low (down 80%+ during my last few months of employment thanks to my own work as an individual contributor), and our stakeholders were satisfied.
And that, paradoxically, became the problem.
When automation is working well, it becomes invisible. The processes run smoothly, the exceptions are rare, and the maintenance demands decrease. To executives reviewing budget spreadsheets, a well-functioning automation program doesn't look like ongoing value creation—it looks like steady-state operations that could be handled with fewer people.
I'd been leading digital transformation initiatives while simultaneously being identified as a target of that transformation. The irony wasn't lost on me, but I didn't fully appreciate it until I received the notice from HR. My position was being eliminated as part of "budget cuts." The role would be absorbed by the team, and eventually a new hire in Poland, where my manager was based.
The mythology around automation always promised that workers would be "freed" for higher-value work. The robots would handle the tedious tasks, and humans would focus on strategy, creativity, and relationship-building. It's a compelling narrative, and in carefully curated case studies, it sometimes even happens.
But in practice, companies rarely invest in retraining displaced workers or creating new roles for them. The logic is simple: if the goal is cost reduction, why would you redeploy someone to a new role when you could simply eliminate the position and capture the full savings?
The automation practitioners—the people who understood both the technical systems and the organizational context—were especially vulnerable. We'd made ourselves so efficient that our ongoing contributions became harder to measure. We'd documented our processes so thoroughly that our institutional knowledge seemed transferable. We'd built systems so robust that they appeared not to need us.
The Human Remainder
There's a particular kind of knowledge that doesn't translate well to documentation. It lives in the space between formal processes and actual practice—the understanding of why certain workflows exist, which stakeholders have competing priorities, what the real constraints are behind the official policies.
When I built an automation, I wasn't just translating a process into code. I was interpreting organizational dynamics, negotiating competing requirements, and building relationships with the people whose work would be affected. I understood which exceptions were genuine edge cases and which were symptoms of deeper process problems. I knew who to call when something broke, and more importantly, I knew how to ask for help in ways that would actually get results.
This tacit knowledge—the relationships, the context, the organizational memory—is what gets lost when you offshore a role or eliminate it entirely. MIT Technology Review has documented this phenomenon across industries: automation projects often succeed in the short term but falter over time as the institutional knowledge that made them work in the first place gradually disappears.
When relationships become tickets and conversations become workflows, something essential is lost. The efficiency gains are measurable. The losses are not—at least not immediately.
A new team member in a different country, working different hours, reporting to a different manager, can certainly maintain the automation systems I built. They can update the code, troubleshoot errors, and respond to service tickets. What they can't easily replicate is the four and a half years of relationship-building, the deep understanding of organizational politics, the knowledge of which battles are worth fighting and which compromises are necessary.
That knowledge doesn't show up in a transition document. It can't be captured in a knowledge base article. And by the time its absence becomes apparent, the person who held it is long gone.
What We're Really Automating
Shoshana Zuboff's work on surveillance capitalism explores how digital systems are increasingly designed not to augment human capability but to extract value by replacing human judgment with algorithmic decision-making. Her argument applies directly to corporate automation: when the primary driver is cost reduction rather than human flourishing, the technology inevitably becomes extractive rather than augmentative.
The question "What should we automate?" is less important than "For whom are we automating?"
If automation serves shareholders by reducing labor costs, the technology will be deployed in ways that displace workers. If automation serves workers by removing drudgery and creating capacity for more meaningful work, the technology will be deployed differently. The code might look similar, but the outcomes diverge dramatically.
I spent years building automation that was presented as worker-friendly but ultimately served a cost-cutting agenda. The presentations emphasized how we were "freeing people for higher-value work," but the budgets told a different story: every automation project had a projected headcount reduction attached to it. That was the real measure of success.
This isn't a technological problem. Automation itself is neutral—a set of tools that can be deployed in service of many different values. The problem is that in most corporate contexts, the values driving automation decisions are shareholder returns and quarterly earnings, not worker well-being or organizational resilience.
When automation is approached as augmentation—as a way to extend human capability rather than replace human workers—the outcomes are strikingly different. Workers become more effective, organizations retain institutional knowledge, and the technology creates genuine value rather than simply shifting costs.
But augmentation requires investment. It means training workers to use new tools, redesigning processes to support human-machine collaboration, and measuring success by productivity gains rather than headcount reductions. It means asking "How can this technology make our people more effective?" instead of "How many people can we eliminate?"
That's a harder sell in a quarterly-earnings culture.
A Forester's Perspective
Before I worked in finance and technology, I studied forestry. I learned to think about systems in terms of sustainability rather than extraction—to understand that healthy forests aren't maximized for short-term timber yields but managed for long-term resilience.
An extractive approach to forestry clear-cuts everything of immediate value and moves on. A sustainable approach recognizes that the forest is a complex system, that short-term gains often come at the expense of long-term health, and that the goal is stewardship rather than extraction.
The parallels to corporate automation are exact.
Extractive automation treats workers as costs to be minimized. It optimizes for immediate efficiency gains without considering what organizational capacity is lost in the process. It measures success in headcount reductions and quarterly savings, not in long-term organizational health or worker well-being.
Sustainable automation would look different. It would treat workers as stakeholders whose knowledge and relationships are valuable assets. It would optimize for human capability rather than human displacement. It would measure success in productivity gains, quality improvements, and worker satisfaction, not just in how many positions could be eliminated.
The technology to build either version already exists. What's missing isn't technical capability—it's organizational will.
Companies claim they want innovation, agility, and institutional knowledge. But when budget pressures arrive, those priorities dissolve. The automation experts are let go, the relationships are severed, and the organizational memory is erased. The systems keep running—for a while—but the capacity to adapt, to innovate, to respond to changing conditions has been quietly extracted.
And when those systems eventually break, as all systems do, the people who understood them are gone.
The Path Not Taken
I don't regret building automation systems. The work itself was meaningful—solving complex problems, improving processes, helping stakeholders be more effective at their jobs. The technology wasn't the problem. The business model was.
What I learned, through my own displacement, is that no one is immune. The assembly line workers whose jobs were automated in the 1980s, the call center employees whose jobs were offshored in the 2000s, the knowledge workers whose jobs are being eliminated by AI today—we're all part of the same pattern.
Even the people building the systems aren't safe. Especially the people building the systems, because we make ourselves so efficient that our ongoing value becomes invisible.
The LinkedIn post I wrote after my termination tried to be gracious. I thanked the team, acknowledged the good work we'd done together, and even recommended the position to people in my network. I meant all of it. The people I worked with were talented and well-intentioned. The systems we built were legitimately useful.
But beneath the professional courtesy was a harder truth: I'd spent four and a half years building systems that ultimately made my own position expendable. I'd documented my work so thoroughly that someone else could theoretically step in without much difficulty. I'd automated processes so effectively that the ongoing maintenance appeared minimal. I'd made myself replaceable.
The tragedy isn't that automation eliminates jobs—it's that we've chosen to deploy it in ways that serve extraction over augmentation, shareholders over stakeholders, quarterly returns over long-term resilience.
We have the technology to build systems that extend human capability, preserve institutional knowledge, and create genuine value. We have the resources to invest in workers rather than replace them. We have the expertise to design automation that serves human flourishing rather than cost reduction.
What we lack is the collective will to ask the right question: not "What can we automate?" but "For whom, and to what end?"
Until we're willing to answer that honestly, automation will continue eating its builders. And the efficiency gains we celebrate today will become the institutional losses we mourn tomorrow.
Next in the series: Essay 7 - Ethics in Retrospect: What Companies Forget When Cutting Costs