Platform Engineering vs DevOps: Mostly a Rebrand

Platform engineering isn’t a new discipline. It’s what DevOps was supposed to be before we let the term get diluted into “developer who also writes Terraform.”

I’ve been working with companies on their infrastructure stories for a while now. I keep seeing the same pattern. Someone reads a blog post about how Spotify or Netflix built an internal developer platform. They get excited. They rebrand their ops team. Nothing actually changes.

The naming problem

Our industry has a compulsive need to mint new labels. We did it with “DevOps” when we meant “ops engineers who can code.” We did it with “SRE” when we meant “on-call but with better job titles.” Now we’re starting to do it with “platform teams” and “internal developer platforms” when we mean “build internal tools so developers stop filing tickets.”

The underlying idea is fine. Good, even. Build self-service paths. Automate the repetitive stuff. Treat your internal tooling like a product. None of this is new. It’s what good infrastructure teams have done for years, and what I tried to build at the fintech startup . We just keep repackaging it.

What a platform has to do

Strip away the branding and you get a short list. Your developers should be able to spin up a service, deploy it, and observe it without waiting on another team. That’s it. That’s the whole thing.

The hard part was never the concept. It’s the execution. I’ve seen companies build elaborate internal platforms that nobody uses because the team built what they thought was cool instead of what developers actually needed. Classic product mistake, applied to infrastructure.

The teams that get it right have three habits:

They start embarrassingly small. One good deploy pipeline beats a half-finished portal with a service catalog. Ship the boring stuff first.

They talk to their users. Your users are the other engineers. If you’re not sitting with them, watching them struggle with your tooling, you’re guessing. And you’re probably guessing wrong.

They don’t mandate adoption. If your platform is better, people will use it. If you have to force adoption, that’s feedback. Listen to it.

The cynical take

Part of me expects the “platform” rebrand to become a way to hire for the same roles at higher salaries. New title, new comp band. I’d get it. Supply and demand.

But the other part of me worries that every time we rename a discipline, we lose institutional knowledge. Junior engineers will think platform teams were invented last year. They miss the decades of operations wisdom that came before. They reinvent mistakes that were solved in 2012.

Do the boring work

If you’re building an internal platform right now, my advice is simple. Ignore the conference talks. Ignore the vendor pitches about developer portals. Go sit with a developer on your team. Watch them deploy something. Count the manual steps. Automate the worst one. Repeat.

That’s platform engineering. It’s also DevOps. It’s also just… good engineering.

Call it whatever you want. Just do the work.