Building Capability

Chapter 1: Make It More Efficient Is Not a Strategy

Before you read — by the end of this chapter you will understand:

Why “make it more efficient” is the wrong starting question

The hidden cost of automating broken processes

The difference between efficiency and genuine capability

Why most organisations are solving the wrong problem - and what the right problem actually is

Let me tell you how almost every technology engagement I’ve ever been brought into starts.

Someone in leadership, usually the CEO, sometimes the operations manager, sits across from me and says some version of the same sentence: “We need to make this more efficient.” They’ve got a process. It takes too long, costs too much, or involves too many people doing things they shouldn’t need to do. They want it automated, streamlined, or digitised. They want the same output for less input. Fair enough.

Except here’s the problem: efficiency isn’t a strategy. It’s a tactic. And if you apply a tactic without a strategy, you just get faster at doing the wrong thing.

I’ve spent thirty years watching organisations invest significant money and time automating processes that, with a little more distance and a few harder questions, they would have realised should not exist at all.

Paving the Cow Path

There’s an old saying in urban planning: don’t pave the cow path.

It comes from the way many older cities were built. Before roads were properly planned, people and animals found the most convenient routes through towns, around obstacles, across fields, between buildings. Over time, those informal paths got worn into the ground. And when it came time to build proper roads, engineers just paved over whatever was already there.

The result was winding, inefficient, sometimes baffling road layouts in city centres that made perfect sense to a cow in 1750 and make no sense to anyone in a car today. Boston is a famous example. The streets weren’t designed, they were inherited.

Most business processes are the same.

They didn’t start as a deliberate design. They evolved as the most expedient thing to do at the time. Someone needed a workaround. Someone else built a spreadsheet. A third person added a column. Someone handed it to a junior who changed the formula. And now the whole organisation depends on a spreadsheet that nobody fully understands, maintained by a person who has been there longest and is the single biggest operational risk the business carries.

When most organisations ask for efficiency, what they’re really asking for is: can you pave this cow path for us?

The answer I try to give them is: what if we planned the road properly first?

The Real Cost of Automating the Wrong Thing

There’s a seductive logic to automating existing processes. You can see them. You can measure them. You can point at the time they consume and the people they require.

The ROI calculation looks simple: if we automate this, we save X hours per week, which equals Y salary cost, which means the system pays for itself in Z months.

Except that calculation almost always misses the most important question: should this task exist at all?

When I sit down with an organisation and genuinely map what their people do against what their customers need, I consistently find the same thing. A significant portion of the tasks on the list - the ones people want to automate - exist only because something else isn’t working properly upstream. They’re compensatory activities. Workarounds for missing information, broken handoffs, or unclear ownership.

Automate those and you’ve just made the compensatory activity permanent. You’ve locked in the dysfunction. You’ve made it faster, cheaper, and invisible - and therefore much harder to ever question again.

Building capability isn’t about doing the same things more efficiently. It’s about asking what you should be doing, who should be doing it, and whether the way the work flows through your organisation actually makes sense given everything that is now possible.

But there’s a deeper cost that rarely appears in anyone’s ROI calculation.

Every hour spent optimising what already exists is an hour not spent on the question of what the business could become. And that’s not a small cost. That’s the difference between an organisation that competes on price and proximity - because it’s doing roughly the same thing as its nearest competitors, just slightly faster or slightly cheaper - and one that has built something genuinely different. Something that can’t be easily copied because it’s not a better version of a common process; it’s a capability no one else in the market has.

Efficiency keeps you in the race. Capability changes which race you are in.

The organisations that commit their technology investment to automation of the familiar end up with a faster, leaner version of ordinary. The ones that ask what they could build that they’ve never been able to build before - those are the ones that become genuinely hard to compete with.

Efficiency vs. Capability: What’s the Difference?

Think of it this way.

Efficiency is getting your existing operation to produce the same output with less time, money, or effort. It’s a worthy goal. It’s not being dismissed here. But it’s inherently conservative - it assumes the thing you’re doing is correct, and just tries to do it better.

Capability is something else entirely. Capability is the ability to do things you couldn’t do before. It’s building new capacity in your organisation, new services you can offer, new quality you can deliver, new risks you can remove, new revenue you can capture.

Here’s a practical illustration. Imagine a professional services firm, say accounting. They’ve got a manual process for onboarding new clients: collecting documents, checking completeness, entering data, chasing anything missing. It takes about three hours per client. They want to cut that to one hour.

That’s an efficiency gain. It’s real. It has value.

But what if, while designing that efficiency, you also asked: what if clients could do most of this themselves, on their phone, at a time that suits them? What if the system checked completeness automatically and sent targeted follow-ups for exactly the missing pieces? What if the onboarding data pre-populated every downstream process so no one had to re-enter anything?

Now you’ve built capability. You’ve reduced the three hours to nearly zero for the firm. You’ve made the client experience dramatically better. You’ve removed a class of errors entirely, and you’ve freed your senior people from data entry so they can do the work that actually requires their expertise.

Same starting point. Completely different ambition. Completely different outcome.

Capability changes what is possible. Efficiency just changes the cost.

What Could We Become?

Most organisations never ask this question. They ask how to get better at what they already do. Rarely do they stop and ask what technology would make possible that their current operation - built around spreadsheets, manual handoffs, and staff-dependent knowledge - simply cannot see.

A spreadsheet is a rearview mirror. It captures what happened. It tells you where you’ve been. What technology makes possible, when you start from the right question, is a forward-facing model of the business: one that shows what’s happening now, what’s likely to happen next, and what levers actually move the outcome.

That shift in perspective opens a completely different set of questions. Here is what they look like:

If we built this as a SaaS platform, who else could use what we know - and what would that be worth?
If we charged for results rather than time, what would we need to build to make that viable?
If customers could self-serve, what does that do to our capacity and our cost structure?
If we moved to subscription income, how does that change the value of the business itself?
If we charged per unit rather than per hour, where does the leverage come from?
With the same staff, could we serve 100 times more customers - and if not, what is the actual constraint?
With an app, is there a market we cannot currently reach at all - a customer who would never pick up the phone but would engage on their own terms?
With real-time connections to suppliers, what happens to our delivery risk, our working capital, our ability to make promises we can actually keep?
With a digital twin - a live model of the operation - what decisions could we make today that we currently make too late, or not at all? What friction disappears when everyone is working from the same live picture?
And underneath all of it: what does this business want to become in the next five years? Because if you’re building capability without answering that question, you’re building toward a destination you haven’t chosen yet.

These are not hypothetical questions. They’re the questions that, when answered, point toward a structurally different business. Not a faster version of the current one. Something genuinely new.

That question - with technology, what could we become? - is the one worth starting with. Everything else is tactics.

The First Conversation I Try to Have

This isn’t always a comfortable conversation to start with.

Most people come to an engagement with a list. They’ve spent time thinking about it. They’ve often already sold the idea internally. They want someone to come in and execute it. When I start asking questions that put the list in question, some people get frustrated.

But the ones who lean into it - who are willing to put the list down for a day and look at the bigger picture first - are the ones who end up with something they’re genuinely proud of. Not just a faster version of what they had, but a business that can do things it couldn’t do before.

That’s what building capability means. And it starts with being willing to ask a harder question than: can we make this more efficient?

The question is: what could this organisation become?

That’s the question worth starting with.