Before You Build Another Tool, Stop

Why unclear processes and siloed workflows are rarely fixed by automation

Introduction: the instinct to build

When a problem shows up in an organization, the instinct is almost immediate.

Something is broken.
Something doesn’t reconcile.
Something doesn’t line up between systems or teams.

The default reaction is often the same:
Let’s build something to fix it.

A script.
A dashboard.
An automation.
A platform.

And to be clear, this instinct doesn’t come from a bad place. Engineers build because building feels productive. Automation feels scalable. Tools feel like progress.

But over time, I’ve learned that not every problem needs a tool — and in many cases, building one too quickly actually makes the problem harder to solve.

When the problem isn’t technical

Many issues that look technical on the surface aren’t really technical at all.

They are structural.

They live in:

• unclear ownership
• mismatched definitions
• overlapping responsibilities
• assumptions that were never aligned

Data not matching across systems is rarely just a data issue. Reconciliation problems are often symptoms of something deeper: different teams solving different parts of the same workflow, in isolation.

When that happens, tools don’t fix the problem — they simply paper over it.

How silos quietly form

In most organizations, each team operates within its own domain.

Different systems.
Different constraints.
Different priorities.

Each team optimizes their part of the workflow in a way that makes sense locally. Over time, small decisions pile up. Workarounds become habits. “This is how we do it” becomes a rule.

None of this is malicious. In fact, it’s usually done with good intentions.

But across departments, these independent optimizations start to collide. Processes drift out of sync. The same data means different things to different teams. Ownership becomes blurry.

At that point, the organization isn’t dealing with a tooling gap — it’s dealing with a coordination gap.

Automation as a band-aid

This is where automation usually enters the picture.

Instead of aligning on how things should work, tools are introduced to compensate for how things currently work.

Scripts are written to reconcile mismatches.
Dashboards are built to explain discrepancies.
Automations are created to bridge gaps that were never discussed.

The tool works — at least initially.

But what it really does is lock in assumptions. It enforces behavior that was never agreed upon. And over time, it becomes harder to change, because the automation itself is now part of the system.

We end up automating around disagreement instead of resolving it.

The overlooked alternative: small alignment

What’s often missing in these situations isn’t technology — it’s conversation.

Small changes at the process level can have outsized impact:

• agreeing on ownership
• aligning on identifiers or access patterns
• clarifying handoff points
• making minor adjustments that help another team downstream

These changes rarely feel exciting. They don’t show up as commits or dashboards. But they reduce friction in a way no tool can.

Not everything needs to be perfect. Not every gap needs to be closed immediately. But small, collective adjustments compound over time and quietly improve the entire workflow.

When manual is faster — and smarter

There’s also an uncomfortable truth engineers don’t like to admit.

Sometimes, doing the work manually is faster than building the tool to avoid it.

Building automation takes time. Maintaining it takes more. And if the process itself is unstable, the automation will constantly need patching.

Manual processes aren’t inherently bad. Used deliberately, they buy time. They allow teams to learn. They reveal where alignment is missing.

Automation should come after understanding — not before it.

Where tools actually belong

None of this is an argument against tools.

Good tools are incredibly powerful — when they’re built on top of clear, agreed-upon processes. Automation shines when it reinforces alignment, not when it tries to create it.

Tools don’t create clarity.
They amplify whatever clarity already exists.

Closing thought

Before building another tool, it’s worth stopping to ask a harder question:

Is the problem really technical — or are we trying to automate our way around a process that was never aligned in the first place?

Sometimes, the most effective fix isn’t another system — it’s a better conversation.