Q and A with Neil Millard - 23rd April 2025 - Platform Engineering

Session summary: a live Q&A on platform engineering and internal developer platforms — discussing when the self-service investment is worth it, the trade-offs against simpler CI/CD and guardrails for smaller teams, and how contracting/consulting factors into platform engineering work.

Welcome, everyone. Today we're talking about platform engineering.

What makes a platform engineering team?

The short answer: infrastructure, build and deploy, developer support, telemetry, and tooling. But what is platform engineering, really? A platform is supposed to reduce cognitive load, increase reliability, and let developers ship code faster. It reduces cognitive load by removing most of the decisions developers otherwise have to make — what should the front end look like, what tool should we use for this — by answering those questions once, up front, and agreeing them into the platform. When a new person joins, you can just say "it looks like this, all these decisions have been made for you, and if you've got other questions, the answer's probably in this document." That gives developers a comfortable place to just get on with developing, with boundaries, guardrails, and tools already set out for them.

The mission

Abstract complexity away from developers, so they can do what they love, which is developing code — most developers don't particularly want to deal with servers, infrastructure, and networks, they want to ship features. As a platform engineer, you provide a reliable environment with clear documentation, and lots of self-service built in, so developers don't have to request something and wait on somebody else — they know where to go, and sort themselves out. The platform needs to be reliable (a build should be available straight away, no wasted time), scalable (as the team doubles, the experience stays the same), secure by default, and ultimately, it should enhance developer experience and productivity — empowering developers to do their best work.

Team composition

• Infrastructure — primarily cloud engineers, looking after cloud, networking, infrastructure as code, and compute — the servers everything actually runs on. Sometimes this includes Kubernetes, sometimes not (if they're clever, they'll avoid it where its complexity isn't worth the value it provides) — but developers don't need to care either way, because it's abstracted away by the infrastructure team. This team also owns security, access, and compliance — least privilege across the infrastructure, so a container can't talk to another unless it's specifically allowed to.
• Build and deploy — owns the CI/CD pipelines. They provide default pipelines, and help developers write custom ones if needed (though that means stepping outside the guardrails, so it's less well supported — most developers are better off just using the default). They own the automation servers, build/deploy/test images, and the deployment strategies — usually decided ahead of time, whether that's blue-green, canary (rolling the new version out to one instance before the rest), or feature flags (my favourite) — all aimed at minimizing the risk of deployment failures, so fast, reliable software can ship without breaking things.
• Developer support — the single source of truth for tools, documentation, and self-service resources, helping onboard new starters quickly, acting as an internal help desk when developers get stuck, and feeding new feature requests and feedback back into the rest of the platform team.
• Observability and telemetry — telemetry gathers data and metrics from the application and infrastructure; observability makes that available through dashboards and alerts. The best telemetry teams don't write every dashboard for you — they provide a couple of good defaults, plus a framework so developers can build their own, focused on what they actually care about. This also covers SLOs and SLAs — a dashboard might show a certain failure rate that's considered acceptable, which helps teams understand and debug their systems when things go wrong, including failures caused by external dependencies outside their control.
• Tooling and automation — the right tools for the job: CLI tools, IDEs, SDKs, and libraries, made available so developers know exactly what they need. This also covers things like secrets management — providing a secure store so a deployment can access a secret without exposing it to anything else — and enforcing consistency and best practices around quality and security.

Collaboration and culture

Above all, a platform team is about collaboration and culture. These teams aren't just allowed to talk to each other, they're encouraged to — when a developer has an idea, the relevant team can say "we tried that, it didn't work" or "great suggestion, we're building it next sprint." Cross-functional collaboration between application teams and platform teams helps solve issues together — on one project, telemetry, infrastructure, and build-and-deploy pooled resources to upgrade a section of the platform in a little under seven months. Documentation matters too — keeping it close to the code rather than buried in a separate wiki: if there's a runbook for an alert, put it right next to where the alert is defined, so when the alert fires, the source points straight at it.

Psychological safety and continuous learning matter as much — blameless postmortems when something goes wrong, focused on why it went wrong and how several small things lined up to cause it, not on who caused it.

Challenges

• Being developers ourselves, we can build things that sound like a good idea but nobody actually uses — worth checking a feature will get enough real utility before building it.
• Empathizing with developer needs, even when a suggestion isn't a good one, and treating it in the spirit it was given.
• Aligning the platform roadmap with business value — the people funding it want to see it's improving the business by making developers faster. One platform I worked on was part of HMRC's COVID service delivery — because the guardrails were already in place, those services were built and deployed within eight weeks.
• Keeping up to date as new tech stacks and tools appear, and deciding when it's worth adopting one.

Measuring success

Developer satisfaction and adoption, feedback, satisfaction scores — one of the best metrics is how quickly a change gets from a ticket through the developer loop into production. Failures will always happen, so alerts and runbooks reduce mean time to recovery. And reduce cognitive load for development teams — make the right thing the easy thing. If it's obvious, easy, and a bit fun, developers will use it; if it's not, they'll find a workaround around it.

Real-world examples and further reading

Spotify's Backstage started life as a service catalog and has grown into a full open-source developer portal you can self-host, though it may be overkill depending on your project. Netflix has its own equivalent tooling, and Spotify has published a lot more on platform teams and DevOps generally — they're something of a trendsetter here. Worth reading: "Team Topologies" by Matthew Skelton and Manuel Pais, and "The DevOps Handbook" by Gene Kim and co-authors, plus "The Phoenix Project" if you prefer a story-driven, more soft-skills-focused read.

Takeaway

Platform engineering isn't just tech — it's culture, mindset, support, empathy, enablement, and evolution, and the goal is making engineers happier and more productive.

One attendee, about to start a platform engineering role, asked for advice going in mostly blind to the specifics of the new company's stack. My advice: don't over-prepare with knowledge you might not need — learn a little as you go, and lean on job descriptions loosely, since they rarely match exactly what you'll actually be doing day to day.

On whether to build or adopt something like Backstage: start with the minimum platform you actually need — most repo hosts already handle basic builds themselves. A lot of what Backstage provides (a UI for secrets management, job tracking) can start out as something much simpler — direct access to your cloud provider's secret store, or even a Trello board — before reaching for an all-in-one platform. Reaching straight for something like Kubernetes or Backstage when you're only going to use a sliver of it costs a lot of cognitive overhead for not much benefit.

On platform engineering versus a traditional embedded-DevOps model: platform engineering pushes automation and self-service far enough that developers don't need to go through DevOps at all — it's just there for them to use. Compared to hiring a DevOps person per team, or a central DevOps team developers raise tickets with, that self-service model scales much better, and management buy-in matters enormously — if leadership backs the platform and makes the easy path also the sanctioned path, adoption follows; without that backing, even a well-built platform struggles against inertia and old habits.