My IT career started in operations management, owning Azure governance, Entra ID hardening, and procurement controls
for a 130+ person organisation. That work taught me what happens when platform decisions are left implicit: access
drifts, spend surprises, and incidents recur because the system rewards restoration over prevention. I fixed what
I could with policy and process, then led a £1M transformation programme that rebuilt the organisation's systems,
culture, and delivery cadence over 18 months. That programme taught me how to govern complex change without losing
the trust of the people doing the work.
What it didn't teach me was how to build the infrastructure itself. So I designed and operated a production
infrastructure R&D environment: bare-metal Proxmox, a k3s Kubernetes cluster, self-hosted GitLab CI/CD, and a full Prometheus/Grafana/
Loki/Alertmanager observability stack. Twenty-plus services, entirely declarative, targeting 99.9% availability.
That platform runs this site, a volunteer cycling campaign group's public infrastructure, and the observability tooling I depend on daily. It proved the architectural patterns I now deploy at work—and proved them at scale, under real operational constraints.
I now work as a platform engineer at Buro Happold, designing Azure infrastructure that product teams self-serve
through golden-path Terraform modules, Azure Verified Modules, and policy-driven guardrails. The pattern I
proved in independent infrastructure R&D, Terraform declares intent, Ansible consumes a derived inventory, layers compose
through explicit contracts, is the same pattern I deploy at work. Only the providers change. That is not a
coincidence. Platform engineering is not about the substrate; it is about the contracts between layers.
I am working toward a principal platform engineer role. Not because I want a title, but because the problems I
care about, governance that scales without heroics, platforms that teams trust, cost decisions made at
architecture time rather than invoice time, sit at that scope. I have built the foundations across
operations, programme delivery, and hands-on engineering. The next step is setting the direction.
How I decide when things conflict
- Clarity over ambiguity.
- Recoverability over optimisation.
- Sustainable platforms over short-term heroics.
- Cost decisions at architecture time, not invoice time.
- Governance that scales without depending on the person who set it up.
If a system or process cannot be explained simply, owned clearly, and recovered predictably, it is not ready to
scale.
