What I Learned Supporting 10,000 Users That Applies to Your Team of 5

There's a thing that happens in almost every first conversation I have with a small business owner. At some point they'll say something like "I know we're only small, so this probably isn't the kind of thing you'd normally deal with."

They're half-apologising for the size of their problem.

And every time, I have to stop them. Because the problems aren't smaller. They're the same problems. The scale is different. The thinking required to solve them is identical.

I spent years leading technology teams at organisations you've heard of. Just Eat Takeaway, with thousands of employees across multiple countries. Penguin Random House, one of the world's largest publishers. Before that, Thomas Cook Online and HiFX. Between them, I was responsible for technology that supported tens of thousands of users.

Here's what I took away from all of it, and why it matters more to a business with five people than you might expect.

Lesson 1: The biggest waste is always the same

At enterprise scale, one of the most persistent problems is tool sprawl. Departments buy their own software without checking what already exists. Teams build workarounds because nobody trained them on the system that's already paid for. Licences accumulate because there's no central visibility into what's actually being used.

Research from Zylo, who specialise in SaaS management, found that companies waste an average of £18 million per year on unused software licences. That's an enterprise number, obviously. But the pattern is exactly the same in a small business, just with fewer zeros.

You're paying for a project management tool your team abandoned after two weeks. You've got three different ways of sharing files because nobody agreed on one. Someone signed up for a CRM during a free trial, upgraded when the trial ended, and now two people use it while the rest keep their contacts in a spreadsheet.

At Just Eat, fixing this required a structured audit. Working through every tool, who used it, what it actually did versus what people thought it did, and whether it earned its place. The process took months across a large organisation.

For a business of five to thirty people, the same exercise takes an afternoon. The methodology is the same. Map what you've got, check what's actually used, cut what isn't, and consolidate where you can. The principles don't change because the headcount is smaller.

Lesson 2: Process problems masquerade as people problems

This one comes up constantly. A business owner tells me their team "just doesn't use the system properly." Or that someone "keeps doing things their own way instead of following the process."

At enterprise scale, I saw this hundreds of times. And almost without exception, the problem wasn't the people. It was the process.

When a team consistently avoids a system or builds workarounds, that's feedback. The system is either too complicated, poorly configured for their actual workflow, or nobody showed them how to use it in a way that made their life easier rather than harder.

At Penguin Random House, I learned that the most effective way to get adoption on any new system or process was laughably simple: talk to the people who'd be using it before you implement it. Find out what they actually do every day. Understand where the friction already exists. Then configure the solution around their reality, not the other way round.

Small businesses skip this step constantly. A founder picks a tool, rolls it out, and wonders why the team reverts to email and spreadsheets within a month. It's not resistance. It's the tool being the wrong shape for the work.

The enterprise lesson: before you blame the team, audit the process. If multiple people are doing the same workaround, that's not a training problem. That's a design problem. And design problems have practical solutions.

Lesson 3: You don't need more technology, you need less technology used better

One of the biggest misconceptions I encounter is that growth requires more tools. More software. More platforms. More integrations. More complexity.

In my experience, the opposite is usually true.

The most effective teams I've worked with, at every scale, were the ones with a tight, well-understood set of tools that everyone actually knew how to use. Not the ones with the longest list of subscriptions.

Research from SecurityBrief UK found that employees across IT, service and operations teams are losing hours each week to fragmented tools and manual workarounds. Their finding was that the average worker switches between fifteen or more applications during their working day. In a large enterprise, some of that complexity is unavoidable. In a business of ten people, almost none of it is.

When I help small businesses now, one of the most valuable things I do is give them permission to simplify. To say "you don't need a dedicated tool for this, your existing platform handles it if you configure it properly." Or "these three tools overlap significantly, pick one and commit to it."

The enterprise lesson: sophistication doesn't come from having more technology. It comes from understanding what you have and using it intentionally.

Lesson 4: The most expensive decision is the one you avoid

At enterprise level, delayed decisions have visible consequences. A delayed platform migration means mounting technical debt. An avoided security upgrade means increasing risk exposure. A postponed vendor renegotiation means overpaying for months or years.

In a small business, the consequences are the same. They're just quieter.

That system migration you've been putting off for eighteen months? Every month you delay is another month of inefficiency, another month of workarounds, another month of your team spending energy on something that could be simpler. The cost isn't dramatic. It's a steady, quiet drain.

A report from Confidence IT found that 82% of UK businesses are experiencing pressure to adopt emerging technologies, but that many struggle to keep pace because they lack the internal confidence or expertise to evaluate what's genuinely relevant versus what's just noise.

This is the gap I saw repeatedly in enterprise settings, and it's even more pronounced in small businesses. At a large company, there's usually someone whose job it is to evaluate technology decisions, even if they don't always do it well. At a small business, that responsibility often falls on the founder or an operations lead who already has a full plate. So decisions get deferred. Not because they're unimportant, but because there's no one with the bandwidth and confidence to make them.

The enterprise lesson: every technology decision you're avoiding has a running cost. It might be financial, it might be in wasted time, it might be in opportunity cost. But it's there. And the sooner it's addressed, the cheaper it is to fix.

Lesson 5: Good enough, documented, and understood beats perfect

In enterprise technology, there's a constant tension between the ideal solution and the practical one. You could spend six months building something bespoke that covers every edge case, or you could implement something that covers 85% of what you need, get it running in three weeks, and iterate from there.

The best results I've delivered have always come from the second approach. Get something working. Make sure people understand it. Document how it works and why decisions were made. Then improve it over time.

Small businesses instinctively do this when they're starting out. They bodge things together, make it work, and move fast. But as they grow, there's a temptation to swing the other way, to feel like everything needs to be "done properly" before it's worth doing at all. And that perfectionism becomes its own form of avoidance.

The enterprise lesson: the value isn't in the perfect system. It's in the system that's understood, used consistently, and documented well enough that someone other than the person who set it up can maintain it. Start there. You can always make it better later, but only if it exists in the first place.

Why this matters if you're running a smaller operation

The government's SME Digital Adoption Taskforce report acknowledged something I've been saying for years: small businesses face the same fundamental technology challenges as larger ones but rarely have access to the same quality of guidance. They recommended a "CTO as a service" model for exactly this reason, recognising that most SMEs don't need a full-time technology leader. They need access to that level of thinking when it matters.

That's what I do now. Not because I got tired of enterprise work, but because I realised the expertise was more needed somewhere else. The founder wrestling with a platform decision that'll shape their next two years of growth deserves the same calibre of thinking as a CTO evaluating an enterprise migration. The problems are the same. The stakes, relative to the size of the business, are often higher.

So if you've ever caught yourself thinking "this is probably too small a problem for someone like that," I'd encourage you to reconsider. The problem isn't too small. It just needs someone who's seen it at every scale and can help you think it through clearly.

That's what a decade of enterprise experience is actually for.

I help small businesses and founders make better technology decisions. Same rigour I applied at Just Eat Takeaway and Penguin Random House, but sized and priced for businesses of 1 to 30 people. If you've got a tech challenge you've been sitting on, let's have a conversation.