Background
Experience
Fifteen years of doing the work before running the businesses. Managed services, business networks, industrial systems, and the operational discipline that makes any of it hold together.
The short version
I started in hands-on technical work and never fully left it. That means I’ve spent time on plant floors commissioning industrial ethernet, in comms rooms at six in the morning before a school day, and in boardrooms explaining why the cheap option will cost more by March.
The through-line is operational reliability. Most technology failures I’ve been called into weren’t caused by the technology. They were caused by nobody owning it, nobody documenting it, and nobody being honest about what it could and couldn’t do. The kit was usually fine. The arrangement around the kit was not.
Fixing that is less glamorous than a rebuild, and it works more often. It’s also much harder to sell, because “we’re going to write things down and agree who owns what” is not a slide that excites a board. I’ve made peace with that.
These days most of my time goes into leading teams and setting direction across the businesses, but I still keep my hands close enough to the work to tell when an estimate is optimistic, and to know the difference between a problem that’s genuinely hard and one that’s just been described badly.
Sectors
Where I’ve worked
Four environments that each taught something the others couldn’t.
Managed services and business IT
Building and running the service side of an MSP: helpdesk, monitoring, escalation, documentation, vendor management, and the unglamorous operational rhythm that separates a real managed service from a break-fix shop with a monthly invoice.
This is the bulk of what I do. The commercial case for it is rarely about technology. It’s about the hours staff lose waiting on things, the licences nobody audits, the tools that overlap, and the downtime that gets absorbed as a cost of doing business because nobody has ever added it up.
It’s also where I learned how much of the job is expectation management. A client who understands why something will take three weeks is a client you keep. A client who was told two days is a client you lose, even if you deliver in one.
Industrial and operational technology
Programmable logic controllers and PROFINET industrial ethernet, where a network fault stops a production line rather than delaying an email, and the cost of being wrong is measured per minute.
The discipline that environment teaches carries directly into every other kind of infrastructure. No changes on a Friday. One change at a time, so you can tell which one broke it. Write down what you did. Know how to undo it before you start. None of that is clever, and all of it survives contact with reality better than clever does.
Education, as a specialism
School networks, classroom technology and campus communications. It’s a genuine specialisation rather than a main focus, because the sector has constraints most businesses don’t: immovable term dates, duty-of-care obligations, and a user base ranging from five-year-olds to principals.
Educational technology is not corporate IT with a smaller budget, and treating it that way is how projects fail. Understanding that difference is why we still do the work, and why it sits under its own service brand rather than being sold as standard business IT.
Founding and running businesses
Hiring, pricing, service design, compliance, cashflow, and the specific discomfort of being the person who has to make the call with incomplete information and a deadline.
Running several businesses at once teaches ruthlessness about what actually deserves your attention. It also teaches you that most problems described as strategic are really just a decision somebody has been avoiding.
Strengths
What I’m genuinely good at
Rather than a list of adjectives, here is what people actually call me for.
Translating between worlds
Explaining a technical decision to a board, and a business constraint to an engineer, without either side feeling patronised. Most stalled projects are a translation failure rather than a technical one.
Inheriting a mess
Walking into undocumented, half-migrated environments, working out what is actually load-bearing, and stabilising it before changing it. The instinct to rebuild first is almost always wrong.
Building the operating rhythm
Turning heroics into process: documentation, escalation paths, monitoring that someone actually reads, and handovers that survive people leaving.
Scoping honestly
Telling someone the work doesn’t fit the window, the budget or the timeline, early, when it’s still a conversation rather than an invoice dispute.
Working across the seams
The failures that hurt tend to live between systems and between suppliers, where nobody believes it’s their problem. That gap is usually where I end up.
Calm during outages
Establishing what is actually known, what is being assumed, and what to try next, in the order that gets people working again soonest. Blame can wait for the postmortem.
Credentials
Qualifications
Certifications prove you sat an exam, not that you can run a network at 3am. They’re listed here as background rather than as the argument.
Education
- Bachelor of Information Technology
Networking and communications
- Cisco Certified Network Associate (CCNA)
- Microsoft Certified IT Professional (MCITP)
- 3CX Advanced Certified
- Yealink Certified IP Phone Engineer (CIPPE)
Delivery and service management
- PRINCE2 Foundation and Practitioner
- ITIL Foundation
- Agile Foundations
Site and safety
- Victorian Private Security Registration (Advise & Install)
- Working at Heights
- White Card
Full professional history is on LinkedIn.
Need an independent read?
Board-level technology advice, a second opinion on a proposal, or help untangling an environment nobody fully understands anymore.