Six Years at Foxtel

I spent several years at Foxtel working across architecture, platform engineering and developer experience. My CV compresses that to a few lines; this post is the story. It’s a reflection more than a record — written from memory, and we did plenty more that I no longer remember.

The Beginning

I joined as a technical architect in 2019. The job was translation: sit between the business and the dev teams, and turn business requirements into technical design. The split was clean — the business defined the what, we (architecture and engineering team) defined the how.

Kubernetes Years and Microservices

Then Kubernetes happened. In 2018–2020 every conference and meetup was about it. With backing from leadership and real enthusiasm from the engineers, we rolled it out — and it was genuinely fun — the kind of shift that changes how teams work, not just where code runs. It changed how we shipped. It also changed the CD half of our CI/CD pipeline. We started from Jenkins X and ended up with Argo CD.

Kubernetes made services cheap to run, so naturally we wanted more of them. The problem was that every new microservice meant repeating the same scaffolding — logging, config, health checks, CI. So we built what we called the bedrock pattern: a shared foundation (golden path) every service inherits, so teams start from a working baseline instead of a blank repo. My manager at the time, Sajid, captured the approach in his write-up of the bedrock pattern. Once bedrock was in place, we could spin up lots and lots of services — cheap, quick, and easy. By the end we were running 500+ Java microservices across products like Binge and Kayo Sports, serving 5M+ users — and holding up 600k+ concurrent streams during peak live sport. And it wasn’t just the backends: the frontends ran on Kubernetes too, with Karpenter scaling the nodes underneath to match the peaks.

All our backend workflows ran on Netflix Conductor, which we later replaced with Orkes — a managed platform built on the same Conductor engine. On the API side, GraphQL Mesh pulled the services together behind a single graph. I was never really a fan of GraphQL, but the choice was a deliberate one and the reasoning held up: it gave us a cleaner separation between frontend and backend, and more autonomy for the frontend teams — they could mix and match APIs, and decouple in time as well: stub against the schema and build before the backend was even ready.

Learning to Release Safely

More services meant more releases, and more releases meant more ways to break production. So the next chapter was all about releasing safely.

We started with feature flags, using LaunchDarkly. Deploying code and releasing a feature became separate decisions — teams could ship continuously and turn things on when ready. Flags led somewhere we hadn’t quite planned: experimentation. Frontend teams loved it. Once you can show a feature to half your users, A/B testing follows naturally, and the business could measure a change before committing to it.

At some point we also brought in Istio. I was the one who pushed for it, and we had a proper argument about whether we actually had the use cases to justify it. We didn’t, really. We brought it in for the capability, on the bet that once it was there, we would use it. The bet paid off: a service mesh, among other things, gave us canary releases and a whole family of rollout styles — progressive rollouts, traffic shaping, circuit breaking, caching, that sort of thing — without touching application code. A lot of application coding issues became infra concerns. It was a bumpy road though: the mesh added latency, but we worked through it.

Head of Platform Architecture

In 2022 I became Head of Platform Architecture, and my days changed shape. Much less designing systems or coding, much more meetings and people management — leading a team of architects. That came with the full people-management load — defining SMART goals and KPIs for each architect — and, less glamorously, owning the budget for a number of our platform vendors: relationships, contracts, invoices. FinOps work sat in there too.

A large architecture team needs structure, so we built some. I defined RACI — between me and my team, and between the architecture team and the other teams — along with ways of working (WOW) with engineering teams or product teams.

For decision-making we brought in ADRs (Architecture Decision Records), which worked much like RFCs: write the decision up, put it in git, and circulate it across the teams so anyone could weigh in. The practice took root, too — squads started numbering and writing their own ADRs for team-level decisions.

We ran weekly architecture review meetings and deliberately invited all sorts — tech leads, developers, business.

We studied fitness functions for keeping architectures honest — though in truth we never got past POCs.

I wrote about how we structured teams around this in Team Structures in Software Engineering.

We’d Built a Platform

With all these pieces in place — bedrock, flags, the mesh, the release machinery — we read Gregor Hohpe’s Platform Strategy and realised that what we had been building all along was an internal developer platform.

So we reorganised everything we had around that central idea and kept adding to it — and started running it as platform as a product: developers were the customers, and the roadmap was driven by their feedback rather than our enthusiasm. Self-service infrastructure was part of that vision too — we proved it out in a small way, though it never grew as far as we wanted.

The front door to all of it was Backstage, our internal developer portal. Golden-path service generation kicked off from there, through a process we called the vending machine — the Backstage scaffolder plus GitHub Actions, generating new services from the bedrock template. Over time Backstage accumulated everything else: the service catalogue, diagrams and dashboards, Kubernetes integration, New Relic, test outputs. If you wanted to know anything about a service, Backstage was where you looked — or at least that was the idea!

Monitoring got the same treatment — New Relic across the services, with dashboards pulled into one place instead of scattered across tools.

It was now time to measure our engineering efficiency. We started with the DORA metrics and tried to measure them ourselves out of Jira, ArgoCD and GitHub — which worked, sort of, until we admitted it was more effort than insight and bought a tool called DX. The numbers moved, too: release cadence went from weekly to multiple deployments a day, and incident MTTR improved. On top of DORA, we explored the SPACE metrics for the non-technical side — developer experience — because delivery speed only tells you so much about how developers are actually doing. SPACE pushed us to actually ask questions. We started running surveys on developer happiness and gathering feedback on our CI/CD pipelines.

Another initiative was testing in production. Rather than sinking endless time into pre-release test cycles, we ran our automated tests, pushed the change to production, and tested there — automatically and manually, with real users, different cohorts, different testers. Big cultural shift. The feature flags from earlier are what made that safe — and it cut our time to market.

Not everything got done, though. We had JaCoCo wired up for unit-test coverage, but between releases we mostly disregarded the numbers. And I always wanted to run CRAP (Change Risk Anti-Patterns) analysis on our Java code — it combines complexity with coverage to point at the genuinely risky methods — but never found the time.

Consumer-driven contract testing was another one: I pushed for it, but it never picked up.

Shifting Security Left

We spent a lot of time on the secure software development lifecycle, and the guiding idea was shift left: catch problems as close to the developer as possible, not in a security review at the end. At pre-commit we ran Trivy, scanning for secrets before they ever left a laptop. On GitHub, Dependabot kept dependencies patched. For SAST, DAST, and SCA (software composition analysis) we had Nullify, and in the cloud, Wiz watched our security posture. It didn’t stop at the pipeline either: in production, Splunk and Auth0 covered runtime monitoring.

The AI Chapter

Then came AI. It wasn’t a standing start — we already had ML in production, with Amazon Personalize and our own models powering recommendations — the “Because You Watched” and trending rows, trained on viewing behaviour and catalogue metadata.

The generative chapter started the way most companies did: GitHub Copilot in everyone’s IDE. We backed it with GenAI practice-sharing sessions, TDD-with-Copilot workshops, reusable prompt libraries, and use-case brainstorming across teams, so what one squad learned didn’t stay in that squad.

Next was an internal RAG system. We pulled HR, Confluence, legal, and data-lake sources into it and built an internal chat assistant on LibreChat, with LiteLLM as the model gateway and role-based access control, so people could just ask questions instead of digging through documents.

The most interesting work was the agentic tech. Like every media company, we had a video pipeline — and a video pipeline turns out to be a very good playground for agents: lots of discrete stages, each a candidate for automation. We ran POCs with Vertex AI on video clipping and video summaries — the kind of work that used to need a human editor. Then we went after the video pipeline itself, running a lot of proof of concepts on replacing parts of it with agents — LangGraph, MCP, human-in-the-loop patterns — turning manual multi-step workflows into autonomous ones with a human checkpoint where it mattered.

We also put AI search head-to-head with the incumbent, A/B testing Vertex AI media search against Amazon OpenSearch.

The Last Chapter: DAZN

My last chapter at Foxtel wasn’t about technology at all. In December 2024, Foxtel was acquired by DAZN, the British sports streaming company, in a deal valuing the company at A$3.4 billion; it completed in April 2025.

It was probably a good outcome for the company and the brand. It was a rough one for the engineering team. Most of what we had built over the past couple of years was migrated and rewritten on DAZN’s tech stack in India. Good product logic but probably a sad thing for the Australian tech industry.

Lastly: everything here was the work of many engineers far smarter than me. They built it.