My career has two beginnings
#The first is security. I started out embedded in one of the world’s leading cyber-security research groups — Royal Holloway’s Information Security Group — where I spent eleven years as a systems administrator. The ISG was the first university anywhere to teach information security, and being surrounded by that meant data protection was never an afterthought; it was the starting point for every decision. I even sat in on the lectures for their world-first MSc. That’s where my security-first instinct was forged — and it has shaped every role since.
Those eleven years were also my manual years. Long before I’d heard the term “Infrastructure as Code,” I was building and running systems by hand — racking servers, imaging desktops, migrating data, learning what reliable infrastructure actually takes. Deep, hard-won, hands-on mastery. (The very first spark came earlier still, on a sixth-form IT service desk, where I built my first Red Hat Linux servers for the fun of it.)
The second beginning is automation. In 2017 I moved to the University of Surrey, and the way I thought about the job changed completely. I learned Chef — my first Infrastructure-as-Code tool — and the idea that infrastructure could be defined as code, version-controlled, tested, and deployed automatically across hundreds of machines rewired everything. I went on to self-teach Ansible, which became my signature tool. I’d spent eleven years doing it by hand; now I was learning to automate it — and you can’t automate well what you’ve never done manually. Suddenly all that hands-on experience had a new purpose.
Two threads, converging
#From there, security and automation became a single thread — and it led somewhere unusual.
I moved into the secure sector, hardening systems and automating deployments for critical national infrastructure at Vodafone. Then into sovereign cloud at UKCloud — the UK’s government cloud provider — automating resilient infrastructure across everything from semi-connected government systems to completely air-gapped, classified environments. Then to SiXworks, a defence digital-innovation partner, where I built a platform team from scratch and delivered automation into classified, air-gapped environments for the RAF’s combat-cloud programme — work that contributed to the capabilities IBM later acquired the company for.
And now to VIB, one of Europe’s leading life-sciences research institutes, where I build secure, automated infrastructure for genomic research and author the governance that keeps it compliant under the EU’s NIS2 directive.
Different domains — telecoms, government, defence, research. The same philosophy throughout: build it once, build it right, make it auditable, automate the parts that shouldn’t be done by hand, and treat your servers like a flock, not a collection of pets.
A second arc: from following the rules to writing them
#There’s a quieter story running alongside the technical one — about governance.
I learned ITIL at Royal Holloway. At Surrey I worked inside a proper change-management process for the first time — peer-reviewed, staged, with proper rollback. At UKCloud those instincts really formed, inside formal ITIL change control. At SiXworks I made the case for an automation-first way of working all the way to the board — and won. And at VIB I now author the policies and processes myself, chair the Change Advisory Board, and hold formal accountability as the FitSM Process Owner for Change Management.
Practitioner, to advocate, to author. It’s the same progression you’ll see in the technical work: from doing the task, to shaping how it’s done, to defining it for everyone else.
Where it’s led
#Two decades in, I’m a DevOps engineer with a rare shape: deep, hands-on automation expertise, forged in some of the most security-constrained environments there are — sovereign cloud, air-gapped defence systems, regulated research. Security-first by training, automation-first by instinct. I came to DevOps from the Ops side — systems-rooted, infrastructure-as-code (more on what I mean by that) — and I build platforms that work, and keep working long after I’ve moved on.
What follows is the detail — role by role.
