Over a decade in IT — from the helpdesk through engineering to leading multiple teams — spent deliberately working across boundaries: security, data, compliance, engineering. That's given me an unusual view of how the parts of a business actually connect. What energises me most isn't managing people — it's solving tough problems and finding better ways to do things, staying hands-on across the whole lifecycle rather than drifting away from the work.
Owned Google Cloud Platform governance end to end — security best practice built in, and infrastructure that stayed governable as it scaled.
Owned IAM across cloud and workplace platforms — Entra ID Conditional Access, access reviews and provisioning done properly, not as an afterthought.
Built ETL pipelines and dashboards that turned raw data into decisions teams could actually act on.
Ran the everyday tools, access and devices a company depends on — Intune-managed endpoints across Windows, macOS and Linux — and made that experience simpler and less frustrating, not just kept it running.
Automated wherever it removed real friction, and introduced tools that spread well beyond where they started — judged on value, not novelty.
Led multiple teams over the years without losing the technical edge that got me there.
Own Client Platform Engineering across RVU's group brands — managing and securing endpoint devices day to day: patch management, one-touch deployment, and the compliance policies that keep them in check. Drive automation as a core team initiative — including introducing n8n as a group-wide platform that started in IT and now runs across engineering — and work closely with cloud infrastructure and AI teams. One foot in IT, one in engineering.
A deliberate blend of IT and security — identity hardening, Conditional Access policy and compliance remediation — with automation doing as much of the manual work as possible, so the value landed on both sides at once.
Worked on the core platform — Kubernetes and Terraform-managed infrastructure — and helped set best practice across the platforms the group built on: GCP and GitHub, as it scaled.
Built data pipelines and ETL processes on RVU's data platform, created dashboards for the business, and supported the analysts who relied on the platform day to day.
Handled 2nd line support and administered core systems — Active Directory, Google Workspace/Office 365 and device management — while working on projects alongside 3rd line and improving internal processes like joiners/movers/leavers and device builds.
Led cloud technology rollout across a multi-academy trust — from procurement and vendor relationships through to staff training — while managing a team of IT Leads and Technicians across multiple sites.
Ran IT across 6 sites with a team of up to 5 technicians, setting service desk standards and administering multiplatform environments spanning Windows, Mac, Google and Microsoft.
Supported schools' networks and ICT equipment, delivering 1st-line technical support to staff and students.
Leading teams has taught me plenty, but the version of leadership I actually value is the unglamorous kind: coaching people, setting a clear direction, and getting blockers out of the way — not sitting between the work and the people doing it.
I've stayed technical throughout, deliberately. I don't think leadership and hands-on work should be mutually exclusive — some of my best calls as a lead came from staying close enough to the work to actually understand what I was asking people to do.
My background is IT-first, but the impact I care about most isn't limited to IT. Compliance, Privacy, Legal and InfoSec are teams I work with directly — helping improve how they work through automation and better process design, not just delivering technology to them.
That cross-functional exposure matters: when I'm building or automating something, I'm not solving it from one lens. I'm bringing the perspective of the teams who actually have to live with the result — which is how you end up with a solution that works for everyone, not just for IT.
I don't like doing things a certain way just because that's how they've always been done. My default is to understand why something works the way it does — and if that reason doesn't hold up any more, to change it.
I judge technology by leverage, not novelty. The question that matters to me isn't whether something is new — it's whether it actually removes friction for the people who have to live with it.
That's part of why I want to keep pulling IT closer to what I see as the new normal: a blend of traditional IT and DevOps, using configuration as code, CI/CD, and the same rigour engineering teams take for granted — rather than treating IT as a separate, manually-run world.
