Twenty years of building systems, and the teams that build them.
Charity · Reading
Technology across the organisation: a cloud-first estate on Azure, Microsoft 365 and Salesforce, service management, cyber security and data, a wish-matching AI agent funded by the Salesforce Accelerator, and the technical foundations for an organisation-wide transformation.
International charity · Oxford
From architecting, and largely coding, the bespoke e-commerce platform behind 500+ shops, to building a 25+ person digital delivery department and writing the organisation's data strategy.
Regulated software, financial services · Slough
High-throughput platforms and multi-terabyte databases for banking clients, a platforms team spanning architecture, engineering and R&D, then leading UK development through an acquisition into a US product organisation, with teams across the UK and India.
Retail logistics · Maidenhead
A greenfield warehouse and logistics system with Arcadia Group, from rugged handheld devices to the web consoles behind them.
Service and retail technology · Reading
Where it started: early self-checkout kiosks at London airports, service desk software built for strict SLAs, and workflow platforms running 24/7 across time zones.
I got into this through Tribes 2 and Command & Conquer rather than a computer science course. Both games had communities living slightly outside the game itself: custom skins, mods, scripts and hidden mechanics discovered by people willing to poke around and see how things worked. I wanted to understand the machinery behind it all, so I started teaching myself.
That quickly expanded beyond the games themselves. The competitive communities I spent time in needed websites, databases, automation and servers, so I built them. Alongside that I was assembling PCs and running home infrastructure long before cloud platforms made spinning up a system a few clicks away, and somewhere along the way the curiosity turned into a career.
I started as a software developer at ESP in 2004, and earned a software engineering degree alongside the job. The work was about as real as software gets: some of the first self-checkout kiosks at London airports, and service desk software built for turnaround times that didn't forgive mistakes. It taught me early that software is judged in production, by people who just need it to work.
Over the next decade the problems got bigger. At M-Netics it was a greenfield logistics system for Arcadia Group, from rugged handheld scanners in the warehouse to the consoles behind them. At Hitec it was financial services: high-throughput transactional systems and multi-terabyte databases for banks, where nobody cares how clever the code is if the numbers are wrong. I went from senior engineer to leading the platforms team. When Mitratech acquired Hitec, I ran UK software development through the acquisition, with teams in the UK and India working alongside product and sales in Texas.
Somewhere in there I noticed I'd become more interested in which problems were worth solving, not just how to solve them. I'd spent a long time helping businesses make money for the sake of making more money, and I wanted what I knew pointed at something that mattered.
That took me to Oxfam in 2019, as solutions architect for the website and e-commerce re-platforming. The website I designed and built as a cloud-native content platform on Wagtail: cheap to run, and hard to knock over. The shop was the harder problem. Oxfam's shops are run largely by volunteers, and together they work like one big distributed warehouse, which no off-the-shelf platform was going to fit. So I made the case for building our own, designed the architecture, built the in-house engineering team and ran the technical tender for suppliers such as the front end. Then COVID arrived and hiring stalled, so I wrote most of the first version myself: a cloud-native product information and logistics platform that takes an item from a shop's listing to an online sale and back to the shop that fulfils it, across more than 500 shops. It's now a multi-million-pound stream of unrestricted income, the money a charity can spend wherever it's needed most.
I went on to lead the architecture function, introducing standards and new career paths for architects. Then I set up and led Digital Delivery and Enterprise Architecture: one department of more than 25 people spanning software engineering, testing, architecture and data governance. As enterprise architect I also wrote Oxfam GB's data strategy, with the capabilities to deliver it, and took both through to organisation-wide approval.
Since January 2025 I've been Head of Technology and Digital Development at Make-A-Wish UK. The charity is setting out to grant many more wishes, and I lead the technical foundations of that transformation. I'm accountable for technology across the whole organisation: infrastructure, digital products, service management, cyber security and data governance. Most of the job is making technology something a growing organisation can put its weight on: dependable, recoverable, and clear about what it costs. I also lead innovation, from AI agents to retrieval-augmented generation over our own data, and the harder part there is letting people experiment early while staying clear about where the consequences are. So far that has meant:
Most of what I believe about running technology, I learned by getting it wrong first.
A technology function doesn't become strategic by saying so. In my experience it gets there when the rest of the organisation can rely on what it says it'll do, and that takes longer than anyone would like. I'd also rather find out than argue: a working prototype settles more than a slide deck.
When leaders can see what each capability costs and what it enables, prioritisation tends to stop being a debate about opinions. And teams do their best work when they're clear, included and trusted. The teams I lead at Make-A-Wish say they are, and I'm prouder of that than of any platform.
Then there's staying close enough to the technology to smell a bad decision, which is really what the next part is about.
It would be easy to read this site as a hobby that happens to be technical. Honestly, it's a bit of both. But building is also how I keep my judgement honest, and how I find out what's possible before anyone has to pay for the answer.
If someone pitches an idea, I can often have a working version by the weekend, which turns "should we?" into "here's what we learned". I build with AI every day, so when an organisation asks whether it's ready to be part of how they work, I've a fair idea where it's brilliant and where it quietly makes things up. And I'm a lot more comfortable asking a supplier about their backup strategy having restored my own from offsite that week.
The projects are real systems I've built, and the home lab is run the way I'd want a production estate run. Musings is where I write up what I learn, including the parts that didn't work.