Then What Will We Do? The Fear Behind Bad Systems

In 2017 I stood in front of a team and explained that the software I was recommending would eliminate a large percentage of the manual work they did every day.

One of them asked a question I always knew was on a large percentage of employees' minds.

"Then what will we do?"

It was a genuine question. All the department did was a lot of manual work.

I was hired to streamline that department so it could operate more efficiently without having to hire more people the more the company grew their clientele. I had spent weeks mapping workflows and tracing where hours disappeared, and I had found the constraint: a desktop application built for their industry, non-cloud, in a year when cloud accounting had been standard for the better part of a decade. It automated nothing. Every report was built by hand, client by client, using commands I had not had to use in over a decade. It crashed regularly, and each crash meant a support call because nothing about it was self-service.

The team was not drowning in clients. Every client simply required three to five times the labor that current cloud-based SaaS could have reduced it to. I built the case, spoke to the possible new software company and confirmed the features, ran the numbers, and presented it. Hundreds of thousands of dollars a year in labor that would not have existed under a modern platform.

The company declined.

Both responses came from the same place.

What the Manual Work Was Protecting

The eight hours of manual data entry were the thing standing between that team and the work that would have made them irreplaceable.

They knew the clients. They knew which numbers looked wrong before anyone could explain why. They had pattern recognition that no software would ever replicate, built over years of touching every transaction in the business. That capability was buried under data entry, and data entry was consuming the hours that capability needed.

Automating it would have freed them to do the work only they could do.

That prospect frightened them, and the fear was not irrational.

A completed task is proof. You enter the data, the data is entered, and nobody can argue with it. Your value is visible, measurable, and defensible at the end of every day. Judgment does not work that way. Judgment can be wrong. Being wrong in front of other people is the thing most working adults quietly organize their entire careers around avoiding.

Manual work is a place to hide from that exposure. It is exhausting and it is safe.

Ask someone to trade the safety for the exposure and "then what will we do" is a reasonable thing to say out loud.

The Company Was Protecting Something Too

Leadership declined the proposal, and for a long time I read that as ordinary risk aversion. It was more specific than that.

They were married to the software.

Significant money had gone into that system — the license, the implementation, the years of workflows built around its limitations. Every one of those dollars argued for keeping it. That is the sunk cost trap in its purest form: the more you have invested in something that is not working, the more expensive it becomes to admit it is not working.

And somebody had chosen it. Software that specialized does not arrive by accident. Someone evaluated the options, made the call, and staked their judgment on it.

Then a person who had been there a few months produced an analysis showing that the choice was quietly costing the company hundreds of thousands of dollars a year.

There is no version of accepting that recommendation that does not also mean accepting the second finding. Approving the migration would have confirmed, in front of everyone, that the original decision was wrong and had been wrong for years — and that the company had fallen behind a standard its industry had already adopted.

The cost of the software was distributed and invisible, spread across payroll thin enough that nobody had to look directly at it. The cost of replacing it would have been concentrated, visible, and attached to a name.

Given only those two options, the expensive one is the one that feels safer.

The team protected itself from being evaluated on judgment. Leadership protected a judgment already made. Same instinct, different altitude — and between the two of them, the system that was failing everybody had a defender at every level of the org chart.

That is why bad systems survive so long. It is rarely one stubborn executive. It is an entire organization, for its own separate reasons, quietly agreeing that nobody has to be exposed today.

The Dissonance Nobody Names

Ask anyone in that department whether they wanted more meaningful work and every hand goes up. Ask whether they felt undervalued and every hand stays up. They were the engine of the entire operation — every transaction, every reconciliation, every record ran through them — and they were the lowest-status group in the building.

Then offer to remove the low-value work that was keeping them there, and watch the room tense.

Ask the founders whether they wanted to grow without adding headcount and the answer was an emphatic yes. It was a stated strategic priority. Then present the only mechanism that delivers it and the answer becomes no.

People defend the exact conditions they complain about. Companies reject the exact solution to the problem they named. This happens constantly, and it happens because the complaint is comfortable and the change is not. A complaint costs nothing. A change requires somebody to be accountable for an outcome.

Naming that dissonance out loud is the first useful thing a leader can do about it.

Why the Fear Is Partly Earned

I want to be fair about something, because this is where most commentary on this topic gets lazy.

The fear of automation is rational given how most organizations have used it. Let me repeat that.

The fear of automation is rational given how most organizations have used it.

When a company finds a way to do the same work with fewer hours, the gain is usually banked as reduced headcount. That has been the pattern for decades. People have watched it happen to colleagues, to parents, to entire departments.

So when leadership announces an efficiency initiative and the team hears a threat, the team is reading the historical record correctly.

Which makes this a leadership problem. If you have never told your people, repeatedly and credibly, that they were hired for their thinking rather than their output volume, they have no reason to believe efficiency benefits them. They will resist quietly — through slow adoption, through workarounds, through an accumulation of small reasons the old way was better. You will pay for the new system and keep the old costs.

If they believe it, they pull the change forward faster than you can implement it and find uses you never anticipated.

That difference is cultural and it is set long before any software decision reaches a vendor conversation.

What Efficiency Is Actually For

The reason to remove work from a human being is to make room for what humans do that nothing else can.

Judgment. Pattern recognition across messy, incomplete information. Knowing which client is about to become a problem, or about to have one, before there is any data confirming it. Designing something that did not exist. Creating.

That is the entire point, and most organizations never articulate it — which is why the efficiency gain so often evaporates into a headcount line instead of showing up as capability.

I have worked this way for two decades now, deliberately. I used every technology available to me as soon as it was released, unless it was too glitchy. Now I use AI across my practice for many things. The hours it returns to me get spent on the work that requires me specifically: reading a client's operation and seeing where the money is actually going, building systems nobody handed me a template for, making judgment calls that carry consequences.

It also returns hours to my life. I run a firm from wherever in the world I happen to be, and that works because I have spent two decades clearing the mundane out of my days — both in my personal life and in business. What I do with the newly opened space every time is my favorite thing in the world: think. Come up with ideas. Start new projects. Build new companies.

That is what the tools are for. Not doing more of the same thing faster. Doing the thing you were actually built to do, which the busywork has been standing in front of the entire time.

The Life That Disposition Built

I never went to college.

I earned a one-year accounting certification at sixteen years old and built everything after that by doing the work in real businesses with real consequences. Nobody handed me a methodology. There was no established system to inherit, which meant I had to design my own — and designing your own is how you end up working at a level of efficiency that inherited systems never reach. What I learned in those years was not accounting. It was what makes a company successful and what destroys it quietly from the inside.

No institution designed that curriculum.

The institutions eventually built curricula for most of what I learned in the field. By the time they did, the people who had gone and learned it directly were already years ahead — and the market had accumulated enough success stories without degrees that the next generation stopped treating the "alternative" path as alternative.

I embraced computers and the internet at fourteen years old. Not cautiously — I was ecstatic about it. I could see that these tools were going to redraw the map of who could build what, and I intended to be standing somewhere useful when they did.

The adults around me were suspicious, and some were hostile. They asked versions of the same question: if the machine does this, what happens to me?

Web 1.0 arrived and the people who moved early built things. A decade later I watched the ones who waited begin to register what had passed them. Web 2.0 arrived and the pattern repeated precisely, with cloud infrastructure and social platforms in place of websites and email. Same fear, same hesitation, same regret arriving on a ten-year delay.

Now AI, same question, louder.

What that disposition produced for me: twenty-one years running my own firm, a team I built and trained across multiple countries, financial infrastructure built for companies across retail, construction, technology, professional services, and multi-entity real estate. A client taken from $3.8M to over $10M with systems that made the growth survivable. A business that operates without me being involved in every transaction.

Of my four children, one went to college. The three who didn't have all started their own businesses — the oldest at 25, the middle at 21, and the youngest at 17.

The one who went has had the harder road, despite a rare and specific natural talent and a degree from one of the top programs in his field. The credential has not opened the doors it promised. He is working on it, and he will thrive — his talent is real and the market will eventually meet it.

My family has lived everything I am describing here. My kids watched the whole thing get built and drew their own conclusions about what actually creates options.

The credential was never the variable — his or mine. What separates the outcomes is a willingness to look at a new tool and ask what it makes possible instead of what it might cost you.

That disposition is free. It requires no institution's permission. Most people never develop it.

Nine Years Later

I left that company very shortly after the recommendation was declined. The software stayed. The manual work stayed. The team stayed exactly where they were, doing exactly what they had been doing.

Over the following years, one by one, nearly all of them left too.

I hope they took their expertise somewhere it gets used differently, and that the work in front of them now is more sophisticated than what they were doing then. I hope the constraint they lived inside for years did not follow them out the door.

Whether they ever found the answer to the question, I don't know. What I know is that it was never going to get answered there.

If your operation is running on systems that cost more than anyone has measured, quantifying that gap is where the work starts. → Book a free 15-min intro call