Platform engineering is not a replacement for DevOps. It's what happens when DevOps works well enough that it creates a new problem.
Here's the sequence most teams miss.

DevOps solves the wall between dev and ops.

Developers own deployments. Everyone automates. Software ships faster. This works well up to 30-50 engineers. Every team manages their own infrastructure. It's messy but manageable.
Then scale kicks in. At 80-100 engineers, "everyone owns their infrastructure" means: 12 teams with 12 different CI/CD setups, 12 different Kubernetes patterns, 12 different approaches to secret management. A new engineer needs weeks to understand how deployments work. A security audit reveals inconsistency everywhere. Senior engineers spend 30% of their time answering other teams' infrastructure questions.

DevOps didn't fail. It created the conditions for a new problem.

Platform engineering solves that problem by building an Internal Developer Platform, a product whose users are your own developers. Instead of each team configuring Kubernetes from scratch, they click "Create New Service", fill a three-line form, and get a fully configured service with pipelines, monitoring, and compliance baked in.
The distinction that matters operationally:
DevOps: every developer owns their infrastructure
Platform engineering: every developer consumes infrastructure through self-service
The platform team doesn't answer tickets. They build the tooling that eliminates the tickets.

The signals that tell you platform engineering is necessary:

Setting up a new service takes more than a day. Your infrastructure team is answering requests rather than building. A security audit reveals inconsistent configurations across teams. Onboarding takes weeks because there are too many different setups to learn.

If none of those apply, DevOps is still the right answer for your stage. Platform engineering before the pain appears is overengineering. Platform engineering after the pain appears is recovery.