How would you tell whether a company's "Platform Engineering" team is genuinely building self-service tooling, versus just being the old ops team under a new name?

Ask how product teams actually get infrastructure or deployment capability: a genuine platform team answer sounds like "self-service through a documented, paved-road tool/template, usually without needing to ask us directly," while a rebranded-ops answer sounds like "file a ticket and we'll provision it for you" — the presence of ticket-based, human-mediated provisioning as the primary path is the clearest tell that the team is still operating as traditional ops, regardless of its name.

The core distinguishing question is about the interaction model between the platform/ops team and the product teams it serves, not the team's title or how it describes its own mission. A few concrete signals separate the two:

Self-service versus ticket-mediated: does provisioning a new service, standing up a new environment, or getting a new database instance happen through documented self-service tooling (a Terraform module, an internal developer portal, a service-catalog-style interface) that a product engineer can use directly, or does it require filing a request and waiting for someone on the platform team to do it manually? Genuine platform engineering treats "product teams serve themselves" as the core deliverable; a ticket queue as the primary interface is traditional ops regardless of the team's name.

What the team actually builds versus what it operates: does the team spend its time building and improving reusable tooling (templates, internal platforms, paved roads) that other teams consume, or does it spend its time directly operating and firefighting individual product teams' infrastructure? A team whose day-to-day work is mostly reactive support tickets and manual provisioning for specific teams is functioning as ops, even if "Platform Engineering" is on the org chart.

Whether product teams have genuine choice, or are simply told what to do: is the paved road actually easier and more attractive than the alternative (genuine self-service value proposition), or is the "platform" really just a mandated process product teams comply with because they have no other option? The former is platform engineering working as intended; the latter — especially if it's imposed on unwilling teams and functions more as an approval gate than an accelerant — often signals a governance/control function relabeled with a platform-engineering title.

Internal customer language and product mindset: genuine platform teams often talk about their product teams as "customers" of an internal product, with the same product-management rigor (roadmap, feedback loops, usage metrics for the platform itself) applied to internal tooling that a real product team would apply externally. A team without any of that framing — just responding to requests as they come in — is operating as a service desk, not a product team.

• The clearest tell is the interaction model: self-service tooling a product engineer can use directly, versus a ticket queue requiring a human to act on your behalf.
• Genuine platform teams spend their time building reusable tooling; rebranded ops teams spend their time on reactive, team-specific manual work.
• A real platform's paved road is attractive because it's genuinely easier, not because it's the only sanctioned option — mandated compliance without a real value proposition is a governance function, not a platform.
• Internal-product framing (treating product teams as customers, with roadmaps and feedback loops for the platform itself) is a strong positive signal when present.

• platformengineering.org: What is an Internal Developer Platform?
• Team Topologies: Platform Teams