Renaming the infrastructure team to "platform engineering" is common, cheap, and changes nothing. The distinction is not organisational — it is about whether the team ships a product or services a queue.
The diagnostic
Four questions. They take five minutes and are difficult to answer dishonestly.
- Can a product engineer provision what they need without filing a ticket? If every environment, database or pipeline requires a request to another team, that is a service desk with a new name.
- Does the platform have users who chose it? A real platform competes with the alternative of teams doing it themselves. If adoption is mandated rather than earned, nobody is getting feedback on quality.
- Is there a roadmap, or a backlog of requests? Product teams decide what to build based on where users struggle. Service teams work through whatever arrived.
- Who gets paged when the golden path breaks? If the answer is the consuming team rather than the platform team, the platform is not accountable for its own product.
Two or more "no" answers and you have an infrastructure group. That is not a criticism — infrastructure groups are necessary and often excellent — but you should not expect platform-team outcomes from one.
Why it shows up in delivery speed
The cost of the ticket-queue model is not the ticket. It is the context switch, the wait, the follow-up, and the workarounds engineers build to avoid the queue entirely. Those workarounds become the shadow platform, and eventually the real one.
Every hour a product engineer waits for an environment is invisible in the platform team's metrics and painfully visible in the roadmap.
What changes when it is a product
Self-service replaces requests. Golden paths replace bespoke configuration. Documentation becomes a deliverable rather than an afterthought. And the team starts measuring adoption and time-to-first-deploy instead of tickets closed.
The single best first move
Pick the most frequently requested ticket type and make it self-service. Not a better form — actual self-service, no human in the loop. It is the smallest change that demonstrates the difference to everyone involved.
A caution
Platform teams fail in a predictable way too: by building an elaborate abstraction nobody asked for, then mandating it. The discipline that prevents this is the same one that makes any product work — talk to your users, watch where they struggle, and be willing to remove things that are not used.
If your platform has features no team has adopted in six months, that is not an adoption problem. It is a product problem.
