I’ve been watching the platform engineering hype cycle with a mix of amusement and frustration. Every conference, every vendor pitch, every LinkedIn thought leader is banging on about internal developer platforms, golden paths, and self-service tooling like they’ve discovered fire. They haven’t. They’ve discovered what competent IT organisations figured out fifteen years ago and slapped a fresh coat of marketing paint on it.

Let me be blunt: if your IT team wasn’t already building internal tooling, creating standardised deployment paths, and offering self-service capabilities to your developers, you didn’t have a good IT team. You had a ticket queue with people attached to it.

The “New” Ideas That Aren’t New

The Platform Engineering community talks about three core pillars: internal developer platforms, golden paths, and self-service infrastructure. Let’s break these down.

Internal developer platforms are just well-organised internal tooling. Back in 2012, I was running an IT team at a national retailer where we’d built an internal portal that let developers spin up test environments, provision databases, and deploy to staging without filing a single ticket. We didn’t call it a platform. We called it “not being a bottleneck.”

Golden paths are standardised, opinionated ways to build and ship software. You know what we called those? Standards. Runbooks. Best practices. Every decent IT team I’ve ever worked with maintained a set of approved architectures, reference implementations, and deployment templates. The idea that developers should follow a well-lit, well-supported path rather than reinventing the wheel every sprint is as old as enterprise IT itself.

Self-service tooling is the one that really gets me. The entire ITIL service catalogue concept — which has been around since the 1980s — is fundamentally about making IT services accessible on demand. We’ve been building self-service portals, automating provisioning, and reducing manual handoffs for as long as I can remember.

So What Actually Changed?

I’m not saying platform engineering is completely without merit. Something did shift, and it’s worth acknowledging. The tooling got better. Kubernetes, Terraform, and the broader infrastructure-as-code ecosystem made it dramatically easier to codify and automate what used to require custom scripting and duct tape. That’s genuine progress.

The cultural shift matters too. DevOps broke down some of the walls between development and operations, and platform engineering is really just the next logical step — dedicated teams whose job is to make other teams faster. ThoughtWorks’ Technology Radar has been tracking this evolution for years, and the trajectory makes sense.

But here’s my problem: the industry is treating this like a revolution when it’s an evolution. And that distinction matters because it changes how you should approach it.

The Danger of Treating Old Ideas as New

When you rebrand established practices as something novel, you create two risks.

First, organisations that already do this well start questioning themselves. I’ve spoken with CTOs running tight ships who suddenly feel behind because they don’t have a “Platform Engineering Team” on their org chart. Mate, you’ve got three infrastructure engineers who maintain your CI/CD pipelines, manage your cloud environments, and build internal tooling. That IS a platform team. You just didn’t rebrand them.

Second, organisations that don’t do this well think they can buy their way into it. Vendors are more than happy to sell you an Internal Developer Platform in a box. But the hard part was never the technology. It’s the discipline. It’s having engineering leaders who understand that internal tooling is a first-class product, not an afterthought. No amount of vendor software fixes a culture that treats infrastructure as someone else’s problem.

What I’d Actually Recommend

If you’re an IT leader looking at platform engineering, here’s my take. Don’t start with the tools. Start with a brutally honest assessment of your current state. Are your developers waiting days for environments? Is your deployment process manual and error-prone? Do you have tribal knowledge locked in three people’s heads?

If yes, you don’t need a platform engineering transformation. You need to fix your basics. Automate what’s manual. Document what’s tribal. Standardise what’s chaotic. Then build from there.

If you’re already doing those things — congratulations. You’re a platform engineer. Update your LinkedIn if you want. The work hasn’t changed.

The best IT teams I’ve seen don’t chase trends. They solve problems. Platform engineering, done right, is just solving the problem of developer productivity with the same rigour you’d apply to any other engineering challenge. It didn’t need a rebrand. But here we are.

Call it whatever you want. Just do the work.