Most people hear "technology consultant" and picture someone turning up with a slide deck and a list of software they want to sell you.
That's not how this works. At least, it shouldn't be.
What actually happens, or what should happen, is a lot less polished than that. It usually starts with a conversation at someone's desk, looking at the thing that's been quietly causing problems for months.
The First Conversation Is Rarely About Technology
I've walked into a lot of construction and trades businesses over the years. And the first conversation almost never starts with software.
It starts with something like: "We can't tell if a job is profitable until weeks after it's done." Or: "My project manager has a spreadsheet that tracks everything, and she's the only one who knows how it works." Or: "We've got Xero, we've got a job management platform, we've got a quoting tool, and none of them talk to each other."
That last one comes up a lot.
The technology isn't usually the problem in these situations. The gap between the technology is the problem. Data that exists in one place but can't get to the place where someone needs it to make a decision. Manual steps that bridge two systems because nobody set up the integration when the second one was bolted on.
So the first thing that happens when I walk in isn't a software recommendation. It's figuring out where the information actually lives, how it moves (or doesn't), and where the bottlenecks sit.
What "System Optimisation" Actually Means at the Ground Level
The phrase "system optimisation" sounds like it belongs in a consulting brochure. In practice, it's usually a lot more mundane than that.
It might mean connecting Xero to a job management platform so that invoices don't need to be manually reconciled every week. It might mean getting timesheet data from the field into the costing system without someone re-keying it at the office. It might mean building a dashboard that pulls from three different sources so the GM can see job profitability this week instead of waiting for the monthly report.
The pattern I see more often than anything else is a spreadsheet doing the work that the gap between two systems can't. Quoting data going in one end, labour hours coming in from timesheets, material costs getting pulled from purchase orders. All manually. Once a week, if someone has time.
And because that spreadsheet is manual, the profitability picture is always lagging behind the actual work. Jobs start and finish under assumptions that haven't been checked against what really happened on the last three jobs, because that data is sitting in a different system that nobody in estimating ever opens.
When you close that gap, when actuals from completed work flow back into the quoting or estimating process automatically, the numbers start changing. Not because anyone's working harder, but because the information is arriving where it's useful at a speed where it's still relevant.
That's what system optimisation looks like for most of the businesses I work with. Not a transformation. Just getting information to the right place at the right time.
The Selection Problem
One of the more common things I end up doing is helping someone evaluate software. Not because they can't Google options, they can, and they usually have, but because the decision is harder than it looks from the outside.
A trades business without a dedicated IT department is making this call through the owner, sometimes the office manager, occasionally a project manager who's been handed the job because they're "good with computers."
They sit through a few demos in a week. Every platform looks great in the demo. The sales reps know exactly which features to highlight. The screenshots are clean. The case studies are polished.
And then down the track, half the team isn't using it. The integration they were promised doesn't work the way they expected. There's a workaround spreadsheet running alongside the new system because it can't quite do what the old one did.
The question I usually ask before anyone looks at software is: what problem are you actually trying to solve? Not "what do you want the system to do" what's the operational problem? Is it visibility? Is it speed? Is it accuracy? Is it the fact that one person holds all the knowledge and if they go on leave, the process breaks?
Because the answer to that question changes which system you need, how you implement it, and what success looks like. A reporting problem and a quoting problem might both lead to the same platform, but the implementation looks completely different.
What Changes, and What Doesn't
There's a pattern that shows up in almost every implementation I've been involved with.
Early on, people argue with the data. "That number can't be right." "My spreadsheet says something different." Sometimes they're right, there's a data gap or something wasn't mapped correctly. But most of the time, they're seeing their operation clearly for the first time, and it doesn't match what they expected.
Then someone starts running the old process alongside the new one. Just in case. That's fine. Trust doesn't come from a training session, it comes from the system being right enough times in a row.
At some point, someone asks a question that the old process couldn't have answered without hours of pulling data together. "Can I see all the jobs where we went over on hours last quarter?" "What's our average margin on residential vs. commercial?" The system answers in seconds. That's usually the moment it shifts from something imposed on the team to something they want.
After that, nobody talks about the system anymore. It's just how things work. The old spreadsheet is still saved somewhere, but nobody's opening it.
That's the other thing people don't expect, the change is gradual, not dramatic. There's no single moment where the business transforms. There's a slow shift from manual to automated, from delayed to current, from one person knowing to everyone having access.
The businesses that get the most out of this process are the ones that start small. One problem. One integration. Get it working, get the team comfortable, then move to the next piece. The ones that try to overhaul everything at once usually stall, because the team can't absorb that much change while still running the operation.
The Measurement Question
The thing I get asked most by MDs is: how do I know this is working?
Fair question. The honest answer is that the early signs are usually qualitative, not quantitative. The office manager stops spending half a day building the weekly report. The project manager starts catching cost blowouts mid-job instead of after invoicing. The estimator starts quoting with actuals from previous similar jobs instead of guessing.
The quantitative stuff follows. When completed job data feeds back into the quoting process automatically, margins tend to tighten up, sometimes significantly, because the estimator is working with real numbers instead of assumptions. When reporting goes from a weekly manual exercise to a live dashboard, the lag between something going wrong and someone noticing drops from weeks to days.
But I'd be lying if I said every engagement produces a clean dollar figure in the first few months. Sometimes the value is in the reporting, the GM can finally see where things sit without waiting until the end of the month. Sometimes it's in risk reduction, removing the dependency on one person who holds a critical process together.
The worst metric is hours saved, because it assumes people were tracking the hours they were wasting in the first place. Most of the time they weren't. The improvement shows up in the things that stop going wrong, which is harder to put a number on but easier to feel.
What a Technology Consultant Should Actually Be Doing
If someone walks into your operation, shows you a slide deck about digital transformation, talks about ecosystems and scalability, and leaves you with a proposal to rip out everything and start fresh, that's not consulting. That's selling.
A consultant should be looking at what you've already got, asking where it breaks, and figuring out the smallest change that makes the biggest difference. Not the biggest change. The smallest one.
Because the smallest change is the one that actually gets implemented. It's the one the team can absorb without the whole operation grinding to a halt. And once that works, the next one is easier. And the one after that.
Most of the best work I've done has been connecting things that were already there. The data existed. The systems existed. The gap between them was where all the cost was hiding.
If that sounds like your operation, we should probably have a conversation.
