About

3 min read
Illustration of Benjamin in a workshop with his daughters, two cats, and a whiteboard about automation, no band-aids, and Wheel v2 architecture.

Opinions expressed for this site are solely my own and do not express the views or opinions of my employer.

I’m a Melbourne-based Cloud Data and AI lead with 15 years in technology, including more than 8 years focused on data, analytics, AI, business intelligence, and cloud delivery.

Most of my work is the bit between the idea and the thing actually running in production. I help shape the approach and stay close enough to the engineering to know whether it will work. Google Cloud is my usual home base, with time spent around AWS, Azure, managed services, and older on-prem environments too.

How I Work

If I have to do something twice, the second time should be documented and automated where possible. Sometimes that takes longer upfront. That is usually still cheaper than leaving the next person to rediscover the same trap.

I do not like band-aids. Short-term fixes have their place, but only when everyone understands the trade-off and there is a path back to a proper fix. Otherwise they become archaeology.

I work best with honesty, direct feedback, and clear ownership. If something is wrong, I would rather say so early and help fix it than let the team quietly carry risk.

I also prefer finishing work properly. Handover, training, and prevention are part of the work, not admin that happens later if there is spare time.

Open Source and Community

I like sharing what I learn. That is the main reason I care about open source, public notes, demos, and community work.

The best technical learning rarely happens in isolation. Someone publishes a half-finished example, a tiny helper, a pattern from a real project, or a blunt note about what failed. Another person finds it six months later and saves a day. Sometimes they improve it. Sometimes they just learn from it and move on. That loop is worth supporting.

Teaching also forces better thinking. If I cannot explain a pattern clearly, I probably do not understand it well enough yet. Writing things down, presenting them, or turning them into reusable code makes the gaps harder to ignore.

I want this site and my public work to be useful enough to help someone else and clear enough that future me can still understand what I was thinking.

A Bit More Personal

I have been pulling things apart for as long as I can remember. At the time it looked like curiosity. In hindsight it was root-cause analysis before I had a name for it.

I am happiest when I have a hard problem, a clear goal, and enough room to understand the system properly. I get bored by repeated manual work, which is usually a sign that the workflow itself needs to change.

Family comes first for me. I am a husband and a dad, and that shapes how I choose where my time and energy go.

Outside work I like motorbikes, learning new tools, and building small systems that teach me something useful.