Curiosity is a quieter force than ambition, but it's usually the one that actually moves you. By the time I'd spent years running a Made-to-Measure department, I wasn't restless in the way people usually mean when they say they want a change — I was curious about a specific thing: the systems sitting just underneath the operation I'd mastered. The scheduling logic, the data that told a supervisor which line was about to fall behind, the software deciding what got made and when. I wanted to be closer to that layer, not further from the floor.
That curiosity is what took me out of textile manufacturing and into product development, R&D, and SaaS implementation — a space where technology meets operations, and where the job is less about running a process and more about building the thing that runs it.
Learning to see software as a production line
At Jaza and then at Groyyo, I found what I still think of as my sweet spot: building and implementing products that solve real operational problems for businesses that look a lot like the one I'd just left. It turned out the years on a factory floor translated directly. A poorly implemented SaaS rollout fails for the same reasons a poorly run production line fails — unclear ownership, untested handoffs, and a gap between how the process is supposed to work on a slide and how it actually behaves once real people are using it under real deadlines.
I wasn't just deploying software. I was transforming how businesses operate — which meant the job started well before a single line of configuration was written. It started with sitting inside a client's existing workflow long enough to understand where the actual friction lived, not where the sales deck assumed it lived.
Every implementation is a small manufacturing problem: define the process, test it under load, remove the steps that don't earn their place.
Designing workflows, not just installing tools
The technical work of implementation — configuring a platform, connecting data sources, migrating records — is the visible part of the job. The harder part, and the part I ended up caring about most, was workflow design: mapping how information should move through a business so that the software amplifies good decisions instead of just digitising bad ones.
I led implementations end-to-end, from the first discovery conversation with a client through to go-live and the weeks after, when a system either earns its keep or gets quietly abandoned. That end-to-end ownership mattered. It's easy to hand off a "successful" implementation on paper and never learn whether the client's team actually adopted it. I wanted to be in the room for both halves — the build and the adoption.
Bridging technology and real-world execution
Working closely with clients meant constantly translating between two languages: the language of what a platform could technically do, and the language of what a warehouse manager, a merchandiser, or a production supervisor actually needed on a Tuesday morning. I'd been on the other side of that translation as a department head myself, waiting for a system to make my job easier instead of harder. That perspective made me a better implementation lead than my technical training alone would have.
I built systems from scratch where none existed, and I helped teams adopt scalable, data-driven processes where the old approach had been intuition and institutional memory. Neither is wrong on its own — but a business that wants to grow past a certain size needs the second one, or growth itself becomes the thing that breaks it.
Two minds, one hard lesson
The clearest version of this chapter's lesson didn't come from a success. It came from a product at Groyyo that never quite became what it should have. I had the privilege of working alongside two genuinely great minds there — two product managers who saw the problem from different angles. One knew the apparel manufacturing industry inside out, down to the details that only come from years on the ground. The other had a different gift entirely: an almost uncomfortable ability to always ask the right question at the wrong-for-comfort moment, the one that punctured a plan everyone else had already agreed to.
Between the three of us, we had industry depth, sharp instinct, and implementation discipline. We still didn't manage to build something truly scalable together in that window, and it's a genuine source of regret. We had professional differences — real ones, about priorities and pace and what "done" meant — and I won't pretend those were comfortable at the time. But they were also useful. Being pushed by two people who each saw further than me in their own direction is exactly the kind of friction that makes you better, even when it doesn't produce the outcome you wanted in the room where it happened.
We ran after features without making the core strong and stable — and a product built that way can only ever be as trustworthy as its shakiest layer.
The feature trap
The specific mistake, looking back with more distance now, was a common one: we ran after features without making the core strong and stable first. Every stakeholder conversation surfaced a new capability someone wanted, and it's genuinely hard to say no to a reasonable-sounding request from a customer or a champion inside the business. But a product that adds width faster than it adds depth eventually starts to feel exactly like it is — a collection of features standing on a foundation that was never asked to hold that much weight.
That experience is where I became genuinely serious about a few things I now treat as non-negotiable in any product or system I build or advise on:
Data and dashboards that mean something. A dashboard that shows numbers isn't the same as a dashboard that shows the right numbers to the right person at the right moment. Most of the reporting I saw built in that era optimised for "can we technically display this metric" rather than "will anyone actually change a decision because of it."
Predictive analysis over rear-view reporting. Reports tell you what already happened, which is useful but limited — by the time a report flags a problem, the problem has usually already cost something. The systems worth building are the ones that give a warehouse manager or a merchandiser a genuine early warning, not just a monthly autopsy.
Actionable intelligence, not just information. Information without a clear next step is just noise with better formatting. The bar I hold reporting to now is simple: if a person can look at this and not know what to do next, it isn't finished yet.
Trust and dependability, above all. A feature-rich product that a business can't rely on is worse than a narrow product that never lets them down. Trust is the actual currency of enterprise software — a merchandiser who has been burned once by bad data will quietly stop checking the dashboard altogether, and no amount of new functionality wins that trust back quickly. That single realisation from Groyyo has shaped every product and process decision I've made since: build the thing people can lean on first, then make it do more.
From operator to problem-solver and builder
Looking back, this was the phase where my own job title stopped mattering as much as the shape of the problems I was solving. I'd started as someone who executed within a system someone else had designed. Now I was the person designing the system — and increasingly, the person deciding which problems were even worth solving in the first place.
That shift, from operator to builder, is subtle but it changes everything about how you show up to work. You stop asking "how do I hit this target inside these constraints" and start asking "are these the right constraints at all." It's a more uncomfortable question, and a more useful one.
By the time I'd spent several years moving between manufacturing operations and technology implementation, I had a rare kind of fluency: I could sit in a factory and speak the language of the floor, and I could sit in a strategy meeting and speak the language of systems and scale. What I didn't yet have was a formal way to connect the two — strategy, finance, and growth as disciplines in their own right, not just instincts picked up on the job. That's what took me to Melbourne, and to an MBA at Deakin University.