Efficiency keeps you in the race. Capability changes the race.
Every technology decision is really a choice between making today cheaper and making tomorrow possible.
Most businesses spend a decade on the first one without ever naming the second.
Why the faster route can still be the wrong road
Walk across any old university lawn and you will find the desire paths — the worn tracks people take because someone once cut a corner and everyone since has followed. Businesses have them too. A form exists because of a system retired in 2016. An approval step survives because of one bad invoice a decade ago. Nobody chose these routes. They accumulated. Convenience became convention.
Then the technology conversation starts, and the instinct is to pave them. Automate the Friday chase-up emails. Digitise the three-signature purchase order. It feels like progress, because something measurably speeds up. But putting a turbo on a lawnmower gives you a fast lawnmower, not a car.
You don’t have an automation problem.
You have a why-do-we-do-this-at-all problem. And it is genuinely hard to see from the inside, because questioning a process feels like questioning the people who built it — usually people who built it well, under pressure, with what they had.
The bottlenecks are rarely in the tasks. They live in the handoffs: the approval that adds no value, the report nobody reads, the gap between two departments where your best people spend their afternoons manually translating between systems that should be talking to each other.
That argument, in full, is in Don’t Just Automate Your Processes — and if you want the version that starts from the customer’s side of the counter, The Three Levels of Digital Transformation sets out what you get back at each level of ambition.
The trap, in one line: the most expensive software you will ever buy is the one that makes a bad process run faster. Read Don't Just Automate Your Processes →
Five questions to ask before you automate anything
Answer these honestly and you will often find you have nothing left to automate — which is the cheapest possible outcome. Swipe through.
Two ways to spend the same budget.
Digitise it as it is
Same work, faster- The existing process is the specification
- Every workaround gets encoded permanently
- Speed improves, coordination doesn’t
- Success measured in minutes saved
- Teams end up working around the automation
Map, delete, then automate
Different work, less of it- The customer’s experience is the specification
- Steps that serve nobody are removed first
- The handoffs are what get fixed
- Success measured in options unlocked
- Teams use it because the work got lighter
Efficiency removes friction. Capability adds strength. You need both — but only in that order, because automating a bad process just gives you bad outcomes faster.
Why strategy and technology cannot be discussed on different days
Most implementation failures start months before anyone writes code. They start in the meeting where strategy was signed off without an engineer in the room — and in the separate meeting, weeks later, where technology was handed a scope and asked to deliver it. A strategy approved without engineering is an approved rework budget.
The symptom is easy to spot afterwards. Manual steps survive a cloud migration untouched, because nobody asked what being cloud-native actually made possible. The filing cabinet moved; the filing stayed. Cloud-native is not a tool choice. It is a strategic assumption about how the business will work, and it has to be made in a room where both halves of the decision are present.
The crossover meeting.
One meeting, before scope freezes, run in a fixed order: outcome first — what are we actually buying? Then capability — which one unlocks that outcome earliest? Then deliverable — what is the smallest build that proves it?
Run in that order, the conversation surfaces the handoffs that should die in the first release, and the metric that will prove belief. Run in the other order, you get a feature list with a business case stapled to the front.
Discovery isn’t rework. It’s how you avoid it. The Crossover Meeting sets the hour out properly — what to ask, in what order, and why an engineer in the strategy conversation costs nothing and changes everything.
Two essays make the wider case: Beyond Efficiency on what cloud platforms make possible once you stop asking them to be cheaper, and The Strategic Edge of Bespoke Software Development on why the fit of a system is a competitive question, not a procurement one.
Why capability compounds while efficiency merely adds
Automation makes existing tasks faster, which is worth having and entirely linear: you save the same hour every week, forever. Capability opens the door to doing something you could not do before, and each layer changes what the next layer can reach.
A back office that runs itself makes room for customers to serve themselves. Customers serving themselves makes room for a market your old model could never have served. None of those steps were visible from the starting line. That is the whole difference: if nothing new becomes possible, you didn’t build capability — you bought speed.
Which is why the honest measure of a release is not minutes saved but options unlocked. The first release kills a handoff. The second adds visibility the first made possible. The third enables coordination the second made affordable. Each one is a bet that buys choices, and sequence turns out to be the strategy — the case for measuring it that way is in Options Unlocked, Not Minutes Saved.
The test: if nothing new becomes possible after you ship it, you didn’t build capability. You bought speed — and speed is the one thing your competitors can also buy. What compounding does over years: The long game →
Why you buy the ordinary and build the thing you compete on
There is a straightforward rule underneath all of this. Buy where you are not trying to be different — accounting, email, file storage, payroll. Nobody ever won a market with a better general ledger. Build where your method is your product.
The risk of standard software is not that it is bad. It is that adopting it means adopting somebody else’s workflow, and when your workflow is what makes you worth choosing, that trade collapses you quietly into competing on price. Your edge should not be a checkbox in someone else’s admin panel.
The build-versus-buy argument, in two essays
Where custom earns its cost, and how the fit of a system becomes a competitive position.
Essay
The Strategic Edge of Bespoke Software Development
When software fits the way you actually work, the advantage isn’t the feature list. It’s that nobody else can buy the same thing.
Read →Essay
Tailoring Software Development for Transformational Success
Why the fit between a system and the business it serves decides whether a project delivers software or delivers change.
Read →
The capability test
Here is the question that settles most technology arguments before they start. If you lost this capability tomorrow — handed it to a generic platform, outsourced it, standardised it away — would your competitive position get worse?
If the answer is no, buy the cheapest thing that works and stop thinking about it. If the answer is yes, you have found the thing worth building. The riskiest choice is never the custom one. It is the one that doesn’t fit the work.
Next: what you already own — Hidden IP → All insights → Book a conversation →