The Tool Was Never the Problem

The Tool Was Never the Problem

We have all watched the cycle. A team adopts new software. Six months of optimism. Then the complaints start. The tool is too slow. The dashboards are wrong. The workflow does not match how we actually work. So they buy another tool. The cycle repeats.

I have seen this pattern in schools, in startups, in established businesses. It is never about the tool.

The tool was never the problem. The problem was the assumption that a tool could fix a process nobody had designed.

Habits Wearing a Process Uniform

Most organisations do not have processes. They have habits. Habits that accumulated over years, shaped by whoever was loudest in the room at the time. Nobody decided them. They just happened, and then they hardened.

Software encodes those habits. When the habits are coherent, the software feels like a gift. When the habits are incoherent, the software makes the incoherence visible, at scale, on a screen everyone stares at every morning. We blame the software because it is easier than examining the habits.

Software Encodes What You Already Are

A tool amplifies whatever exists underneath it. Order underneath, order on the screen. Confusion underneath, confusion with better graphics.

This is why the demo goes well and month three goes badly. The demo runs on the vendor's process. Month three runs on yours. The gap between the two is the most expensive lesson in software procurement, and almost nobody budgets for it.

The Map Comes Before the Market

The real work happens before any tool is chosen. You map how information flows through your organisation. Where does a decision begin? Who needs to see it? What happens to the output? Where does it get stuck? What gets lost between departments?

Draw it on a whiteboard. Then watch what happens when five people draw it. If you get five different diagrams, you have found the real problem, and it cost nothing to find. It is the highest-stakes question in the room, asked at the cheapest possible moment.

The second test is harder. Take one real decision the organisation made last month and trace it end to end on that whiteboard. Where the trace disappears is where work actually lives, and where the next tool will quietly fail.

When you answer these questions, the tool choice becomes obvious. Sometimes you need a CRM. Sometimes you need a shared document. Sometimes you need to remove a layer of approval that exists only because someone added it three years ago and nobody questioned it since.

Why CRM Implementations Fail

In Best Practices Are Not Strategy, published in this journal last week, the argument was that the shared playbook gives everyone the same architecture and nobody an advantage. Tools follow the same law.

The CRM does not fail because it is bad. It fails because it was asked to solve a problem that existed before it was installed. It was asked to create structure where there was none. No software can do that. Software can only encode structure that already exists. If the structure is unclear, the software encodes the confusion and makes it harder to see.

The Migration Trap

The expensive version of the cycle looks like this. A frustrated team, a new tool, a migration project, six months of optimism, the complaints, another migration. Each migration costs more than the last and teaches less than the one before.

Eventually the market runs out of tools to try. That is the moment the organisation finally meets the process it never designed. It usually calls that meeting an emergency.

Fix the Map First

The next time your team is frustrated with a tool, stop. Before you start evaluating replacements, ask: do we know how our work actually flows? Can we draw it on a whiteboard and have everyone agree? If the answer is no, the tool is not the problem. The problem is the thing you have never mapped.

I designed Evuve around this principle. We do not start with technology. We start with the flow. We map the institution, design the architecture, and only then ask what tools fit the design. The answer is often smaller than the client expects. They arrive wanting a platform. They leave understanding their own organisation, with a system that supports it. The platform is one piece. The architecture is the product.

The queue of tools waiting to be blamed is long. The unmapped process behind all of them is usually one thing.

A mapping session is not a luxury item. It is a morning, a wall, the four people who actually move the work, and someone whose job it is to ask why at every step until the answers stop being embarrassing.

Fix the map first. Then the tool stops mattering, because the right one becomes obvious.

Full archive: https://evuve.co.uk/journal

Cover image: Christina Morillo on Pexels.