“Platform engineering” now describes two very different things. One is a funded team that owns paved paths, measures adoption, and treats developers as users. The other is the ops team renamed, still doing tickets. Survey data increasingly separates them, and the gap is wider than the shared job title suggests.
The CNCF and SlashData Q1 2026 Technology Radar, based on more than 400 professional developers using cloud native technologies, found 28% of organizations have a dedicated platform engineering team, while 41% manage platforms through a multi-team collaboration model. The tooling itself has settled: Helm, Backstage, and kro sit in the “Adopt” position for application delivery, with ArgoCD, Buildpacks, GitHub Actions, and Jenkins in “Adopt” for workflow automation, and cert-manager, Keycloak, and Open Policy Agent for security and compliance.
Tool maturity is not the constraint anymore. The constraint is what teams do with them.
The maturity model is about behavior, not tooling
The CNCF Platform Engineering Maturity Model grades platforms across five dimensions — investment, adoption, interfaces, operations, and measurement — at four levels: Provisional, Operational, Scalable, and Optimizing.
The useful thing about that framing is that none of the dimensions are “which tools did you install.” A team running Backstage, ArgoCD, and OPA can sit at Provisional if requests still arrive as tickets and nobody measures whether anyone uses the platform. A team with a well-documented Terraform module set and a CLI can be Scalable.
The dimensions that separate levels in practice:
Interfaces. Provisional platforms are consumed by asking a human. Operational platforms have a documented request path. Scalable platforms have self-service that works without the platform team being awake. If provisioning a new service requires a person on the platform team to act, everything downstream is capped.
Adoption. The distinction is whether teams use the platform because it is the easiest path or because they were told to. Push-based adoption survives exactly as long as the mandate does. Pull-based adoption means the golden path is genuinely faster than going around it — which is a statement about the platform’s quality, not its policy.
Measurement. This is the most commonly skipped dimension and the one that makes the others unfalsifiable. Without adoption and satisfaction data, a platform team cannot tell whether it is building paved roads or speed bumps.
What the platform has to actually provide
Strip away the product names and a platform that clears Operational has to answer a specific set of developer requests without a ticket:
- Provision a new service — repository, CI pipeline, deploy target, DNS, TLS, secrets scaffolding, and observability wiring, from one command or one form.
- Deploy a change — with rollback that works and a status surface the developer can read.
- Get credentials — scoped, rotatable, and never pasted into a chat.
- See what is running — inventory, ownership, dependencies, and cost, tied to the same service identity used everywhere else.
- Understand a failure — logs, traces, and metrics reachable from the service page rather than four separate consoles.
Each of those is a product decision before it is an infrastructure decision. The technology to do any of them has been commoditized for years; what has not been commoditized is deciding which variations you will not support.
Paved paths require saying no
The failure mode that produces the most expensive platforms is supporting everything. A platform team that accepts every language, every deployment topology, and every exception ends up maintaining a matrix nobody can test and developers still cannot self-serve, because every path is bespoke.
A golden path is a commitment: this stack, this pipeline shape, this deployment pattern, supported and fast. Teams that need something else can have it, but they own the difference. That trade needs organizational backing, because the first team that wants an exception will escalate, and if exceptions are free, the golden path degrades to a suggestion.
The corollary is that platform scope should be narrow at the start and expand only where measurement shows demand. The common sequencing error is building a service catalog and a developer portal before there is a single automated provisioning path worth cataloging.
Backstage is a portal, not a platform
Backstage sits in “Adopt” for good reason, and it is also the most reliable way to produce a platform that looks finished and does nothing. A portal renders a catalog and launches templates; it does not provision, deploy, enforce, or observe. Installing it before the underlying automation exists produces a directory of services with broken links.
The sequencing that works: automate one provisioning path end to end, in whatever interface is cheapest — a CLI, a repo template, a pipeline. Get it used. Then add the portal as a discovery surface over automation that already works.
The AI workload question is a scoping question
The CNCF data shows 35% of organizations using hybrid platforms that combine existing developer tooling with AI-specific tooling, and describes hybrid approaches as the emerging dominant model for AI workflows — organizations adapting what they have rather than standing up parallel infrastructure.
That is the right instinct for platform teams under pressure to “support AI.” GPU scheduling, model artifact storage, and inference endpoints are new resource types on an existing platform, not a reason to build a second one. The parts that generalize — identity, secrets, deployment, observability, cost attribution — should not fork. What genuinely differs is narrower than the vendor framing suggests.
A starting checklist
If you are standing up or auditing a platform, the questions that predict whether it will work:
- Can a developer provision a new service without a human on the platform team? If no, nothing else is worth optimizing yet.
- Do you know how many teams use the platform, and whether they would choose it if it were optional?
- Is there a written golden path, and does the organization back the cost of deviating from it?
- Does the platform own developer-facing outcomes (time to first deploy, deploy frequency, failure recovery) or infrastructure-facing ones (uptime, cluster count)?
- Is the portal, if any, sitting on top of automation that already works without it?
Platform engineering being the default has made the tooling decisions easy and the organizational ones no easier. The teams that clear Scalable are not the ones with the best Kubernetes setup — they are the ones that treated the platform as a product with users who can leave.