The Hidden Cost of “Automating Everything”

Why your bots, scripts, and tools might be building chaos instead of clarity. Automation without orchestration is a road to nowhere.

If you’re not a subscriber, you can still grab DDL’s free guide Leading Better 1:1s. It’s packed with questions, feedback tips, and a simple roadmap for better 1:1s.

✅ Reflective questions (Quiet Leadership style)
✅ Feedback prompts (Radical Candor made practical)
✅ A simple step-by-step conversation roadmap

---

Hej! It’s William!

My dear reader… I’ve lost count of how many times I’ve walked into a room and someone proudly told me, “We’ve automated the process.” Usually followed by a slide. A beautiful dashboard. Metrics pointing up. Manual steps leading down. Alerts are in place. Even a chatbot is doing something somewhere.

It feels like progress. They’re excited.

I’ve been there too. That initial rush of making something move without you.

But now, every time I hear that line, I slow down. Not to kill the buzz, but to ask what no one wants to hear out loud: what happens when the process fails?

Not technically, but practically.

When the customer doesn’t respond. When one team updates the rules and the other team doesn’t know. When something breaks and no one owns the exception.

That’s when the real system shows itself. And more often than not, it’s a mess wearing clean data.

Automating what’s broken

There is something off about how we talk about automation at work. We often act as if automating a task is proof that we have improved it. But rarely do we stop to ask if the task itself made sense in the first place.

We boast about making things faster. But faster than what? The same confusing handoffs that already frustrate everyone? The same unclear requests where no one knows who is supposed to do what? Making that mess run faster does not fix it. It only hides the confusion until it turns into a bigger problem.

Automation has become a way for companies to show they are modern and efficient. It is an easy signal to investors, customers, or bosses. But it is often shallow. Speed is easy to measure. Coherence, the idea that all the steps actually fit together and make sense, is not.

So companies optimize for speed and assume coherence will follow. It usually does not. Coherence requires people to stop and ask tough questions. Who is responsible for what? What is the goal? Where does information get lost? These are uncomfortable questions because they expose problems in how teams work together.

Most people avoid them. Not because they are lazy, but because it is risky. It can mean challenging old habits, changing someone's job, or admitting that the process was broken all along. So instead, we automate the existing mess and call it progress.

If we want automation to be truly useful, we need to treat it as a test of our design. Does this process actually make sense before we speed it up? Are roles clear? Are we solving confusion, or just moving it faster?

These questions are not technical. They are organizational. And they are hard. But they are necessary. Because the real risk is not that people are too busy to examine their processes. It is that they are afraid of what they will find if they do.

The orchestration vacuum

In many companies where I have worked or advised, there is always this moment when someone says with genuine surprise, “I thought this was already solved.” They are not shocked because someone failed at their job, but because they assumed the process had an owner, a clear system, or at least someone accountable for the whole.

When the problem surfaces, it becomes painfully clear that no one was actually responsible for the end-to-end outcome.

This missing piece is what I think of as orchestration.

It is rarely absent because people are lazy or incompetent. It is absent because no one was asked, explicitly, to think about the entire flow.

Each team was given its own fragment of the process, its own software, its own metrics, its own incentives. Naturally, they focused on making their part better. That was what success looked like to them.

But work does not respect those boundaries. Customers do not care which team owns step four. They experience the whole journey.

The risk team might not know what the operations team has automated. The chatbot may keep sending polite messages to a disconnected process that no longer works.

This is the orchestration vacuum. It is not the result of bad intentions. Everyone is trying to do their job well. But the system itself is broken because it fails to reflect how the work actually needs to flow across teams, systems, and goals.

---

Do you want to unlock many more systems to become a better leader? Subscribe now and get 20% off your first year

Paid subscribers unlock:

🔐 Weekly premium issues packed with frameworks and/or templates
🔐 Access to special toolkits (check the Starter Kit already available below)
🔐 Strategic guides on feedback, influence, and decision-making
🔐 Exclusive content on career growth, visibility, and leadership challenges
🔐 Full archive of every premium post

Plus, you get a Starter Kit when you subscribe, which includes:

🔓 Feedback & 1:1: Meeting Templates, Feedback Cheat Sheet, Conversation Scenarios

🔓 Stakeholder Management & Influence: Stakeholder Power Map, Expectation Tracker, Influence Playbook, Communication Templates, Conversation Planner

🔓 Weekly Planner: Weekly Planners A & B, Time Audit & Meeting Review, Start / Stop / Continue Reflection, Leadership Focus Reset, 33 Activities for Weekly Planning

---

No one wants to own the flow

We often hear that “someone should own the flow,” but in practice, very few want that role. Because owning the flow is not just about managing tasks.

It means handling the politics, the constant ambiguity, the late handoffs, and the problems that fall between teams yet belong to no one.

It also means challenging local optimization. It requires saying no to a team’s proposed automation if it causes friction elsewhere. That is rarely welcome.

Especially in organizations where teams compete for headcount, visibility, and internal credibility. In these environments, teams start to treat their automations like prized assets. Their slice of the process turns into their product. They lose sight of the fact that it was always meant to be part of something larger.

When you try to reconnect those fragmented pieces, it is not just a technical integration. It is a negotiation. It is a matter of identity. It demands shifting people’s thinking from “my delivery” to “our delivery.”

In my experience, that is far more difficult than drawing an ideal swimlane diagram or writing a clean process map.

Visibility is not enough

It’s tempting to believe that if we just make the process visible, people will want to fix it… I’ve believed that myself at some point in the past. :)

Visibility helps, but it does not drive real change. It does not shift incentives. It does not make cross-functional work less political. Often, it only makes the pain harder to deny.

I have watched teams gather around a process map, all agreeing it is broken, then walk away unchanged. Not because they do not care or are incompetent, but because fixing it properly would impose costs on the people least equipped to bear them. Those without a budget. Without authority. Without the mandate to say yes or no. So the problem remains in place, fully visible, completely unresolved.

That is the organizational paradox. We devote months to automating steps that barely matter, polishing local efficiencies that look good on a dashboard, while carefully avoiding the harder discussion about how those steps actually connect.

We call it digital progress because it is easier to measure than to negotiate.

Why do we resist orchestration

This is the part nobody likes to talk about. Orchestration sounds great in strategy decks, but in real life, it messes with all the quiet agreements that keep things comfortable.

It challenges autonomy. Teams love owning their piece, but they rarely want to answer for how it fits into the bigger puzzle.

It slows things down… at least at first. Coordinating across boundaries feels painfully sluggish compared to quickly automating your own silo.

It messes with incentives. Who gets credit for fixing problems that live in someone else’s budget? Usually, no one. So why bother?

Worst of all, it ruins plausible deniability. Once you see how the system really operates, you can’t pretend it is just a tooling problem. You can’t unsee the bottlenecks, the handoff failures, the contradictory goals. You have to admit that the company’s way of working needs to change.

And you will not solve that with a prettier form or another chatbot.

So what do we do instead?

Start from where it hurts. Pick one process that already breaks often.

Not the ideal one, but the one that people already talk about in frustration. That’s your test case. Trace it without illusions. Don’t use diagrams that assume logic. Use sticky notes.

Start by asking people what they actually do, not what they think should happen. Pay attention to where things jam up. When someone admits, “Honestly, I just send an email manually when this breaks,” treat that like gold. That is your real process documentation, right there.

Next, map the pain, not just the steps. Look for confusion, delays, dropped handoffs, and responsibilities that vanish into thin air. That is what orchestration is meant to solve. Not to make things faster for its own sake, but to make them clear.

Once you can see the mess honestly, automation finally has a place. It is not the solution by itself, but the reinforcement of good design. Automate only after you know who owns the process, what it relies on, and what happens when it fails.

If you skip that and rush to automate, you are not creating a streamlined system. You are building a ghost process. One that seems to work until it suddenly doesn’t, leaving everyone wondering what went wrong.

I used to think automating a task was always progress.

It felt efficient, modern, and clever.

But I have learned the hard way that when the underlying process is unclear, automation just locks in the confusion.

When no one owns the outcome, automation becomes a monument to blame-shifting.

And when the structure is broken, automation will not fix it; it will make the chaos faster and harder to untangle.

The real difficulty is rarely technical. It is structural, cultural, and behavioral.

It is about incentives that reward quick wins instead of sound design, about teams that want speed without clarity, about leaders who admire dashboards but ignore friction.

You cannot automate your way out of ambiguity. You have to design your way into coherence. That means asking harder questions, the kind that slow you down now, so you do not break things later.

Who is responsible for the result, not just the task?
Who is willing to design for flow, not just throughput?
What are we building here, really?
A system that is fast, or a system that makes sense?

If you cannot answer these, then maybe it is time to pause the applause for your latest automation and pay attention to the friction instead.

Because friction is not the enemy, it is the signal. It shows you where the real process lives, messy and human. And that is the only place real improvement ever starts.