What 15 Years in Enterprise IT Taught Me About Solving Small Business Problems

I started my IT career on a service desk. Not in a glamorous way — fielding calls, logging tickets, resetting passwords. It was unglamorous work, and I learned more from it than from anything that came later.

From there I moved into application development, then into leading delivery teams, managing major incidents, building governance frameworks, and advising on enterprise service management platforms that touched thousands of users. Fifteen years in, I completed a Graduate Certificate in Cyber Security at the University of Adelaide. I kept learning because the problems kept changing.

When I stepped out of enterprise to work independently with small and medium businesses, people assumed I was downshifting. I wasn’t. I was taking the most useful things I’d learned and applying them where they’re actually needed.

Here’s what fifteen years taught me — what carries over, and what you can safely leave behind.

Every Technology Problem Is Actually a People Problem

This took me years to fully believe, but it’s the truest thing I know about IT.

In enterprise, we’d spend months selecting, configuring, and deploying a platform — then watch it fail because nobody wanted to use it, nobody had been trained properly, or two teams had conflicting ideas about who owned the process. The technology worked. The people didn’t have what they needed to make it work for them.

Small businesses aren’t different. When a business owner tells me their CRM isn’t working, I don’t start by looking at the CRM. I start by asking: who was supposed to enter data, and what got in the way? Nine times out of ten, the answer isn’t a software problem. It’s a clarity problem, a habit problem, or a trust problem.

The technology is usually fine. The system around it needs attention.

The Simplest Solution That Works Is Always the Right One

Enterprise IT has a bias toward complexity. It’s built in. Large organisations have procurement processes, vendor relationships, compliance requirements, and the inevitable tendency to over-engineer solutions because the stakes feel high.

Small businesses don’t have that luxury — and that’s actually an advantage.

When you can move quickly, you should. When a spreadsheet genuinely solves the problem, use the spreadsheet. When an off-the-shelf tool does what you need at a fraction of the cost of a custom build, start there. Complexity is a liability. Every additional system is something that can break, something that needs maintaining, something someone has to learn.

I spent years watching enterprise teams build elaborate solutions to problems that didn’t need elaborate solutions. It made me very practical. If I’m recommending something to a business I work with, I want it to be the simplest thing that actually solves the problem — not the most impressive thing we could build.

Governance Sounds Boring Until You Need It

Governance is the word that makes people’s eyes glaze over in every room I’ve ever been in, small business or enterprise. But the underlying concept isn’t complicated: it’s having basic rules about who makes decisions, who has access to what, and what happens when something goes wrong.

In enterprise, poor governance creates sprawl, security gaps, and costly cleanups. In small business, it tends to create a different problem — everything lives in one person’s head, or one person’s accounts, and when that person leaves or something breaks, the business is in trouble.

I’ve seen small businesses lose access to their own systems because credentials were stored with an old contractor. I’ve seen business owners locked out of platforms they’d been paying for years because the account was registered to a former employee’s email address. Basic governance — an asset register, documented access, a simple decision framework — would have prevented all of it.

You don’t need enterprise-level bureaucracy. You need a few sensible rules and someone to keep them.

You Can’t Fix What You Don’t Measure — But Measure Outcomes, Not Activity

Enterprise taught me the discipline of measurement, and also its failure mode.

The failure mode is measuring the wrong things. In large organisations, it’s easy to produce dashboards full of activity metrics — tickets closed, emails sent, meetings held — that tell you very little about whether anything important is actually improving. Activity looks like progress. Sometimes it is. Often it isn’t.

What I’ve learned to focus on is outcome measurement. Not “how many emails did we send this month” but “did our response rate improve.” Not “how many hours did we spend on IT this quarter” but “how many incidents did we avoid.” The question isn’t whether you’re busy. It’s whether the things that matter are getting better.

For small businesses, this doesn’t require complex analytics. It requires deciding in advance what success looks like, and checking on it regularly.

The Biggest Risk Is Always the One Nobody Is Talking About

After years of major incident management, I developed a reliable instinct: the risk that surfaces in a postmortem is almost never the one the team was worried about.

Everyone focuses on the visible problems. The project is behind schedule, the integration is unstable, the vendor is slow to respond. Those get attention. What doesn’t get attention is the quiet assumption that turns out to be wrong — the backup that was never tested, the dependency nobody had documented, the single point of failure everyone assumed was covered.

In small business, the equivalent is usually cybersecurity. It’s not top of mind because nothing has gone wrong yet. Cybercrime targets small and medium businesses disproportionately, precisely because defences tend to be minimal and response capacity is limited. The risk is real. It just doesn’t feel urgent until it is.

Part of what I do is name the risks people aren’t talking about. Not to alarm anyone — to prevent the thing that’s predictable but not yet visible.

What Doesn’t Translate From Enterprise

Not everything I learned in enterprise is useful at smaller scale, and it’s worth being honest about that.

Enterprise timelines don’t translate. Months of planning and phased rollouts make sense when you’re managing change across a thousand users. For a team of ten, that pace is a liability. Small businesses need to move in days, not quarters.

Enterprise costs don’t translate. The tools and vendors that made sense at scale are often wildly disproportionate for a small business. There are excellent, affordable alternatives — and choosing them isn’t compromising, it’s sensible.

Enterprise bureaucracy doesn’t translate. The approval chains, the change management processes, the governance structures that exist to protect large organisations at scale — they create friction that small businesses can’t afford and don’t need in the same form.

What does translate is the quality of thinking. Systems thinking. Problem decomposition. Understanding that technology decisions have long-term consequences. That’s not enterprise-only. That’s just good practice.

One Problem at a Time

In enterprise, projects try to solve everything at once. That’s often why they take so long and why so many of them fail.

When I work with small businesses, I solve one problem at a time. We identify the most pressing issue, we fix it, we prove the value, then we decide what to do next. It’s not a project — it’s a practice.

Over time, that approach creates something more valuable than any single project: a technology partner who actually knows your business. Who understands your systems, your team, your constraints, and your goals. Who can see problems coming before they arrive.

That’s what fifteen years in enterprise, and working independently since, has taught me to build.

If you’re a business owner who wants that kind of thinking applied to your technology — without the enterprise overhead — I’d be glad to have a conversation. You can reach me at davebock.au/contact.