“Men have become the tools of their tools.” – Henry David Thoreau, Walden (1854), “Economy”
A founder I was speaking with had spent nearly a year choosing the right business system. He had researched it properly, taken references, brought the team along. Six months after it went live, he was sitting across from me trying to work out why everyone seemed busier than before. Not happier, nor freer. Just busier. More notifications. More exceptions that needed a human eye. And a good deal of time spent reconciling what the system reported with what people believed was actually happening.
None of this was what he had imagined at the start of the technology adoption. The whole point of the investment had been to take work off the team and give him back some room to think. Instead, the business felt fuller, more effortful, slightly harder to see through. He had reached the conclusion most people reach at that point, which was that he had either bought the wrong tool or that the team had not adopted it properly.
Both are reasonable explanations. But both are usually wrong, or at least incomplete. Neither of us was in a hurry to say so, though, because the feeling in the room was not really about the software at all. It was the sharper discomfort of having done something sensible and watched it fail to yield the expected results.
The paradox that isn’t one
The thing that makes this so disorienting is that the tool is usually working exactly as it was designed to. Nothing is broken. The reports generate. The reminders fire. The data flows from one place to the next. If you called the vendor, they would walk you through the screens and everything would be functioning to specification. The work has simply increased, or moved, or multiplied, and it has done so without anyone deciding that it should.
I have watched the same piece of software go into two businesses of roughly the same size and produce almost opposite results. In one, it settled in within weeks and the team barely mentioned it again, the way you stop noticing a good chair. In the other, it became a standing item on every management meeting for the better part of a year. Same product, same price, same training. The difference was never in the software, and it was never going to be found by looking at the software.
What the tool had done, in both cases, was take in the processes of the business it was installed in and hand them back, amplified. One business it flattered. The other it exposed.
That is the part worth thinking about. A tool often changes a business less than it reports on it, at volume. It takes whatever is already there, the organisational clarity or the absence of it, and gives it pace and reach. We tend to buy business technology expecting it to add something the business lacks. More often it reveals what the business already does.
Acceleration without direction
What a tool reliably adds is pace, reach and visibility. It moves things faster, sends them further, and shows more of them to more people. What it does not add, and has never been able to add, is direction, ownership or judgement. Those have to come from somewhere else, and in a growing business they often come from somewhere that was never made explicit.
Bringing a tool in has a way of asking questions the business had managed to avoid answering. Who actually owns this customer record? When is a lead genuinely qualified, as opposed to merely interesting? Who is allowed to approve an exception, and how large an exception? Which of the three numbers floating around is the real margin? When does a project move from likely to committed? For years, in most growing businesses, these things were settled by habit, by proximity, by the judgement of whoever had been there longest, or by a quick word with the founder on the way past his desk. The ambiguity was real, but it was familiar, and familiarity made it manageable.
A business system does not allow that kind of comfortable vagueness. It needs the answer encoded somewhere, in a field, a rule, a workflow, a permission. And if the answer was never actually agreed before it was encoded, the system does not resolve the uncertainty for you. It preserves it and then distributes it, faithfully, to everyone at once.
Where real direction already exists, pace compounds it, and the business genuinely does more with less. Where direction is missing, pace compounds the gap instead: faster cycles of the same confusion, more reports that nobody acts on, quicker routing of decisions to people who were never in a position to make them. McKinsey has long argued that transformation outcomes depend heavily on whether the organisation changes enough around the idea to make it work. The leverage was always going to come from the business. The tool only multiplies what it is given.
When visibility arrives before authority
One of the most common things a new tool delivers is sight. Suddenly there are dashboards, cleaner status updates, live figures, a view into corners of the business that used to be dark. The founder can see more. The managers can see more. The team can sometimes see more of one another’s work than they ever could before, which feels like progress and often is. But seeing a problem and being able to do anything about it are two quite different things, and a tool tends to deliver the first long before the business has sorted out the second.
A sales manager who can now watch margin erode in real time may still have no authority to change a price. An operations lead who can see the same customer exception recurring week after week may have no standing to challenge what sales has already promised. Finance may spot slippage earlier than ever and still need to wait for the founder to make the call, because the call was always the founder’s to make. The tool has helped everyone see more. The decision still has to travel the same route it always did, through the same narrow point, arriving at the same desk.
Better reporting can make a business look more mature than it is. The dashboard suggests control. The underlying behaviour suggests founder dependency.
There is a common view that you should sort out your structure before you invest in your business technology. I’m not entirely convinced by that, because it is too neat and it lets the discomfort off too lightly. Better visibility does not always show you a problem you can fix. The dashboard is not lying. It is showing you exactly where the bottleneck lives, in colour, every morning.
The friction the tool inherits
When a tool is installed, the friction that was already in the business rarely disappears. It changes shape. A manual handover that used to happen with a nod across the room becomes a workflow stage. A conversation that used to take place at the founder’s desk becomes an approval button. A judgement call that someone used to make on instinct becomes a dropdown field with four options. Everything looks more organised afterwards, and a good deal of it is. But organised and resolved are not the same thing, and the gap between them is where the trouble tends to settle.
It helps to notice the difference between friction that has been removed and friction that has merely been relocated. Removing it means the underlying question got answered and the work genuinely got lighter. Relocating it means the question is still open, but it now lives inside the system. Encoding an unresolved decision does not just preserve it in its unresolved state. It dresses it up as settled. A dropdown field looks like somebody made a choice about what those four options should be. An approval flow looks like somebody owns that approval. The form implies a organisational clarity the business never actually reached, and because it looks deliberate, it becomes harder to question.
People assume the thinking was done, because why else would it be in the system. Underneath each of these small frustrations is almost always a question of decision rights, and how the business is meant to run. The kind of thing that was never settled and has now been rendered in software, where it is both more visible and oddly more protected from challenge. The tool is not the villain in any of this. The problem is what the business expected it to sort out.
Why it worsens as you add more
A growing business almost never approaches technology adoption one tool at a time. It adds a customer system, and then a way of running projects, and then an assistant of some kind, and then a layer of reporting on top, and then automated reminders to chase the things that keep slipping, and then a set of integrations to make all of these talk to one another. Each decision, taken on its own, looks reasonable. Most of them are reasonable. The difficulty is what happens in the spaces between them.
Every new business system arrives and asks the organisation to define the same things again, slightly differently. Each one wants to know who owns what, who is allowed to do what, how the data should be shaped, where the exceptions go, who gets told when something breaks. Where the business has genuine answers to those questions, each addition slots in and the whole arrangement does start to behave like leverage. Where the business does not, each new tool inherits the existing ambiguity and passes a fresh copy of it along the chain.
What you end up with is not a clearer business. It is a denser, faster, more interconnected version of the confusion you already had, now running across six platforms instead of in one person’s head. And at that point the systems begin to disagree with one another, producing competing versions of reality that all look authoritative and cannot all be true. The instinct, when this happens, is almost always to reach for another tool to reconcile the others. It is worth noticing how rarely that works, and how often it is the very thing that makes the confusion harder to escape.
The question that should have come first
Underneath every one of these stories is a question that almost never gets asked out loud before the money is spent. Not which tool, which is the question everyone does ask, at length, with spreadsheets. The harder one is rarely voiced: what were we actually hoping this would resolve for us? It is a question a tool can never answer, because tools carry out decisions, they do not make them. And yet a great deal of business technology gets bought in the hope that it will somehow do the deciding.
Listen for the hopes that sit just beneath the business case and you start to hear the same few, again and again. The hope that the new system will force alignment that the team has been unable to reach on its own. The hope that it will tidy up an ambiguity nobody wanted to confront directly. The hope that it will instil a discipline the business has never quite managed to hold itself to. Each of those is, when you look at it squarely, a decision the founder was reluctant to make, handed off to a piece of software in the hope that the software would make it for them. It rarely does. It cannot.
What it does instead is take the unmade decision and run it, faithfully and at speed, in whatever half-formed state it was handed over. Experienced operators come to recognise the moment I mean. It is the moment just before the purchase, when organisational clarity was needed and was not there, and a tool was bought to stand in its place. Whether a tool ends up removing work or merely digitising it tends to come down to whether that clarity existed before the order was placed, or was being outsourced to the order itself.
Leverage, or efficient dependency
I think back to the founder six months in, his team busier than before, the system humming along exactly as designed. He had not bought the wrong tool. He had bought a very good one and pointed it at a business that had not yet decided a handful of things it needed to decide, and the tool had done what good tools do. It had taken the business as it found it and made it run faster. The bottlenecks ran faster. The founder dependency ran faster. The unsettled questions got asked and re-asked faster, and louder, across more screens.
Which leaves a question that is more uncomfortable than it first appears. The last significant tool your business brought in, the one that was meant to take work off everyone’s plate. Did it build you genuine organisational leverage, the kind that means the business can do more without leaning harder on the same few people? Or did it simply take the bottlenecks and the dependencies and the decisions you had been avoiding, and make all of them run more efficiently than ever? And if you are honest with yourself for a moment, sitting where you are now, are you entirely sure you would be able to tell the difference?
If you enjoyed this article you can subscribe here to receive future articles.
—
0 Comments