Reflections on forty years in the technology trenches, and why successful systems are built on human readiness, not just good code.
I have been building and implementing business software for over forty years now. I’ve seen the green-screen terminals give way to client-server, watched the desktop empire crumble in the face of the web, and eventually found my home in the open-source world of Odoo, where I had the privilege of becoming Australia’s first partner.You would think that after four decades, the lessons I value most would be about technology. About databases, frameworks, or the latest clever architecture. They aren’t. If I had to distil everything I’ve learnt into a single sentence, it would be this: Technology is rarely the problem; people, understanding, and time are far more important.It took me a good portion of my career to truly understand that. When you are young and technical, you tend to believe that every business problem has an elegant code-based solution. But the older I get, the more I realise that the software is almost always the easy part. Here are the lessons that experience—and a fair share of mistakes—have taught me along the way.
Lesson 1: Listening for the "Why," Not Just the "How"
Early in my career, if a client told me they wanted a button that turned the screen blue and printed three copies of an invoice, I would build them a button that did just that. I prided myself on giving the customer exactly what they asked for. What my younger self didn’t realise is that customers rarely ask for what they actually need. They ask for what they think is possible, usually based on the limitations of the system they are currently using.I’ve come to believe that the most valuable thing a consultant can do is resist the urge to start building. Instead, you have to sit with people. You have to watch them work. You have to ask "why" until you feel like a curious child rather than a seasoned expert. Once you understand the underlying human reality—perhaps that the owner needs to see overdue debtors before leaving for the day, or that warehouse staff have only seconds to enter a delivery—the standard Odoo workflow often solves the problem perfectly. But you can only see that if you’ve taken the time to look. A deep understanding of each customer issue is vital, and it takes an unblinkered approach to find the best solution.
Lesson 2: Customisation is a Symptom, Not a Solution
This brings me to a belief that might be slightly controversial: excessive complexity is often a symptom, not a solution. And the person introducing that complexity isn’t always the client. When I see a system that has been over-customised—so modified that it is very difficult and time-consuming to upgrade and the client feels locked in—I don’t see a unique business; I see a discovery process that failed. My advice, as a general rule, is always to keep customisations for after implementation. Adapt your workflows to the standard system first. Live with it. Let the team use it. Only once you see where the standard system genuinely fails should you reach for the custom code. More often than not, you’ll find you didn’t need it.
Lesson 3: The 80/20 Rule of ERP Success
I have a simple rule that I share with new customers: A poor technical solution, implemented well, will succeed, while a great technical solution, implemented poorly, will fail. I’ve seen technically "perfect" systems—logic-tight and beautifully architected—sit unused on the shelf. They failed because the staff found them too complex and quietly went back to using secret spreadsheets on the side.Failures very rarely stem from the technology itself. They stem from people and operations. They happen because we forgot to train people properly, because we didn't get buy-in from the floor, or because we underestimated how much a new process disrupts a human being’s daily routine. Success isn’t measured by the elegance of the architecture; it’s measured by adoption. A simple system that the whole team embraces is infinitely more valuable than a sophisticated one that everyone ignores.
Lesson 4: The Myth of "Best Practice"
The software industry loves the phrase "best practice." It implies there is a single, correct way to run a business. But after forty years, I’ve learned to be wary of it. I prefer to think in terms of "appropriate practice."A "best practice" implementation that completely overwhelms a ten-person business is, in reality, bad practice. If you jump too quickly and try to implement every module on day one, you risk becoming a business disruptor that actively harms the company you were hired to help. You have to meet clients where they are. This means honestly reading a customer's resources, their appetite for change, and their technological readiness. Best practice is a destination you grow toward; it is never the starting line. Giving a client a system they can actually operate tomorrow morning is far more important than handing them a theoretical ideal they’ll never reach.
The Goal is Craftsmanship
People sometimes ask why I’m still doing this work after all these years. The honest answer is that I’ve stopped finding the technology interesting for its own sake. What keeps me engaged today is the craftsmanship—the satisfaction of understanding a messy, human problem and finding a way to make someone’s working day just a little bit easier.The tools have changed beyond recognition over my career, and they’ll keep changing long after I’ve stopped. But the fundamentals never really do. Listen carefully. Resist the urge to over-build. Respect the people who have to use what you create. And remember, always, that technology is rarely the problem. People, understanding, and time are far more important. That is where the real work begins, and where the best systems are made to last.