Strategy that survives contact with reality
I work in the space between technology strategy and making things actually happen. My territory is AI and agentic systems, enterprise transformation, systems thinking, developer productivity, and the work of helping people grow through complex technical change.
Most of that space is messy. The technology moves quickly, the incentives inside a real organisation rarely line up neatly, and a confident one-line answer is usually dishonest. I am more useful exposing the trade-offs, testing the assumptions underneath a plan, and turning the result into something a team can actually build and live with. That beats producing another slide that sounds impressive and changes nothing.
That perspective comes from building, not just advising. I have worked in C#/.NET and API development, in JavaScript and Angular, and in Laravel and PHP. I have built accounting integrations on the Xero API, the kind of work where an unexamined assumption shows up as somebody else's broken ledger. And I have mentored developers through apprenticeships, which is where I learned that explaining a system clearly is a test of whether you understand it yourself.
That mentoring work is also where I part company with the current consensus on AI. The prevailing view is that AI belongs with senior engineers, because they can tell when it is wrong, and that juniors should be kept away from it. My view: we should enable seniors to use AI, and we should empower juniors with a harness. Keeping the tool from juniors treats judgement as a fixed personal trait rather than something a system can supply, and it quietly concedes that the tool cannot be made safe. Build the harness instead, and the people still forming their own judgement are the ones with the most to gain.
What I think about
AI that works in reality
AI matters when it changes how real work gets done. That means paying attention to architecture, operating models, and engineering practice, not just the demo.
Enterprise transformation
Modernisation is not a technology swap. It is a system of constraints, incentives, legacy choices, people, and execution, and treating it as anything simpler is how transformation programmes stall.
Systems thinking
I try to make dependencies and trade-offs visible rather than hidden behind reassurance: the kind of model that explains why something works, where it breaks, and what changes when one variable moves.
Execution over theatre
A compelling idea earns credibility through implementation. I would rather show the decisions, the constraints, and what was learned than the pitch.
Mentoring through complexity
Knowledge compounds through people. Explaining a difficult thing clearly, without dumbing it down, is part of the work, not a separate activity from it.
How I work
I try to separate what I know from what I am assuming, and I say which is which. I would rather frame a trade-off honestly than hand over a false certainty that feels better in the room. If an idea sounds impressive but does not help a serious reader think or act more clearly, I treat that as a sign the idea is not finished yet.
The writing on this site and the code linked from Work are the actual record of that. Read them rather than take my word for how I think.