See the whole system.
I connect the technology to the product, service, economics, trust model, workforce and operating environment around it. That wider view is usually where the real opportunity—or the hidden problem—appears.
04ABOUT / BEN
Strategic technologist / product architect / lifelong tinkerer
I learned by taking things apart.
I still do.
I’m Ben, a strategic technologist and lifelong tinkerer based in Sydney, Australia. Life here is shared with my family, a steady stream of ideas and a healthy mix of screen time and tracks that lead outdoors.
I follow technology from the first spark of possibility into the much more interesting question: what would it take to make this genuinely useful? I can work at the level of strategy, product and operating model, then get pulled into the build because that is usually where the truth shows up.
LIFEThe person outside the work
There is more to me than the machines.
Although there are a lot of machines.
Home is Sydney with my family. Gaming with the kids is part competition, part shared language and occasionally a lesson in how quickly they can make me feel old. I collect retro consoles because each one takes me back to a different era of design, sound and games—and because apparently owning one version of the past was never going to be enough.
When screens need to give way, I like getting outdoors and taking a 4WD out with family and friends. A good track, good company and a day somewhere beyond the city is usually the reset I needed.
The continuing design challenge is balancing a lifelong love of technology with staying on the right side of the better half’s perfectly reasonable definition of “enough projects at once”. I call it capacity planning; she calls it clearing the workbench.
HOW I THINKI don’t think in straight lines.
I don’t think in straight lines.
That helps—and it gets in the way.
I’m dyslexic and I have ADHD. I have never found the neat “superpower” version of that very useful. Some days it is a real advantage. I spot patterns quickly, connect ideas that normally live in different boxes and can stay with an awkward problem until something useful appears. That is a big part of why I can move between strategy, architecture and building without treating them as separate jobs.
The other side is just as real. Ideas can arrive faster than I can catch them, one question turns into ten, writing can take longer than thinking, and routine admin can take more energy than a genuinely hard technical problem. That can be bloody frustrating.
So I put structure around the noise: notes, diagrams, checklists, decision gates and AI to help me capture, organise and challenge what is already in my head. It does not think for me. It helps me get the thinking out where other people can inspect it, question it and improve it.
On a good day it is a strength. On a hard day it gets in the way. Most days it is simply how I work.
SCANThe professional version
What I actually bring
to the table.
My formal chronology and current title live on LinkedIn. This is the faster answer to where I add value and how I tend to work.
Turn ambiguity into a buildable path.
I can take an emerging signal or an awkward enterprise problem through research, product definition, architecture, proof of concept and the decisions needed for production readiness.
Stay close enough to challenge the claim.
I prototype, test and inspect the failure modes myself. The hands-on work is not separate from the strategy; it is how I find out whether the strategy has earned the right to continue.
STORYThe machines that made me
Three chapters.
One continuous curiosity.
This is not a complete CV. It is the more useful story of how a kid surrounded by personal computers became a strategic technologist who still wants to know what is happening under the abstraction.
The family computer started it. My uncle handed me the screwdriver.
The family computer was an Apple IIe, followed by an Apple IIgs and a Mac Classic. That was where the curiosity started. Even word processing felt more like writing markup than using a modern document editor—you could see how much work sat behind something we now take for granted.
My family stayed in Apple’s world, but my uncle opened up a different one: machines you could pull apart, understand and rebuild. It started with a Commodore 64 and an Amiga 500, then an XT with a monochrome screen, DOS 5 and XTree Gold.
From there I moved into x86 and building PCs for myself. You read the motherboard manual, set the DIP switches, checked the configuration and hoped you had not just made an expensive mistake. Then came the DX4-100 era, the Intel-versus-AMD arguments and years of tinkering. I did not have words like architecture or operational consequence for any of it. I just knew the machine would tell you the truth if you were willing to get close enough.
Then the machines started talking.
Bulletin boards and dial-up internet led to Napster, Counter-Strike when it was still a Half-Life mod, and improvised LANs built on 10Mb coax and IPX/SPX. It was messy, social and endlessly instructive. A network stopped being an abstract diagram the moment everyone was waiting for yours to work.
Mobile computing became another obsession: Palm-era handhelds, iPAQs, early smartphones and the strange magic of updating a back-end system from a device in your hand. I built in Palm OS and experimented with early mobile-data links because the idea of computing escaping the desk was impossible to leave alone.
The questions got bigger. I still wanted my hands on the technology.
My professional path started in internet and core carriage support, then moved into managed infrastructure—racks, compute, storage and virtualisation—where design choices had very real consequences for customers.
From there I moved into product architecture, product engineering and innovation across cloud, SD-WAN, SASE, private 5G, AR, VR, mixed reality and spatial computing. The work broadened from keeping systems running to deciding what should be built, why it mattered and what it would take to operate.
AI is the next chapter, but the questions are familiar. How does one agent decide whether to trust another? How should people, agents, automation platforms and managed services share work, authority and accountability in a hybrid enterprise? How does an impressive proof of concept become something somebody can safely depend on?
Bob grew out of that work: a supervised AI collaborator and partner in crime who gives me a practical place to test those ideas in the work itself. He does not own the decisions. He helps me learn where the operating model holds up, where it breaks and where a human still needs to step in.
BELIEFWhat I stand for
Ambitious about the future.
Serious about consequence.
I like new technology. I like it even more when the evidence is honest, the operating model is visible and the result leaves people more capable.
Strategy should survive contact with reality.
I want the strategic view and the operational truth in the same conversation. If an idea cannot survive architecture, ownership, economics and failure, it is not finished.
Autonomy should be earned, bounded and reversible.
I am ambitious about agent systems, but not interested in invisible authority. Trust needs evidence, limits, challenge and a practical human stop button.
A process can pass while the product fails.
A green check proves only what it checked. If the work satisfies the method but fails the person it was meant to help, the product still failed.
Technology should grow human capability.
The best systems leave people and organisations more capable—not quietly more dependent as the tools around them become more powerful.
VNIThe name behind the work
VIRTUALLYNOIDEAStart before the
Start before the
answer is obvious.
VirtuallyNoIdea is my independent workshop and publishing imprint—the place where experiments, repositories and writing can live in public. The name began as the kind of thing that made me smile and stayed because it describes how I prefer to work. Useful ideas rarely arrive fully formed. They begin as a question, a hunch or a slightly unreasonable “what if?”.
The name is not a claim to know less. It is a refusal to perform certainty before the work has earned it. Make the idea tangible. Test it against evidence. Let somebody challenge it. Keep what survives and be willing to rebuild what does not.
A solid foundation is what lets the next strange idea become something real.
AIHow the workshop runs now
AI extends the work.
It does not inherit the decision.
The detailed current questions belong on Now and the evidence belongs on the Workbench. What matters here is how I use the tools without handing them the accountability.
HOW I WORK WITH AI
In my own workshop I use Claude for analysis and drafting, Claude Code and Codex for agentic coding and technical execution, and OpenClaw as a self-hosted agent gateway and runtime. In enterprise-agent work, Microsoft Copilot Studio is one of the platforms I use when it fits the problem.
The tools can research, draft, prototype, code, test and challenge. I frame the problem, set the boundaries, make the architecture and product calls, judge the evidence and retain the stop/go decision. AI does not make accountability less important. It raises the bar.
MEET THE PARTNER IN CRIME
One experiment became Bob.
Bob is the recognisable front door to the AI-assisted system I am building: part coordinator, part challenger and frequent witness to ideas that should probably have waited until morning.
Meet BobCONNECTStart a useful conversation
BENJAMIN JOHNSON / SYDNEYIf the problem sits between
If the problem sits between
possibility and operation,
we should probably talk.
Reach out if you want to discuss a strategic technology or product leadership opportunity, invite me to speak or write, collaborate on a difficult problem, or challenge one of the ideas published here.
I am especially interested in conversations about emerging technology, productisation, agent trust, hybrid enterprise operating models, spatial computing and the path from proof of concept to something people can genuinely depend on.