Google Cloud just stopped treating platform engineering as a tribal discipline and started treating it like product management with KPIs that matter to execs. The report doesn’t hedge: platform teams should operate as product teams, instrument developer outcomes with DORA-style metrics, and push self-service through an IDP UI — not dashboards of tickets.
Lots of companies have chased “platform-as-product” as a slogan; Google’s report makes it operational. It prescribes three concrete shifts that will force a redesign of how platform teams measure, prioritize, and ship features.
First: measure developer outcomes, not ticket throughput. The report foregrounds deployment frequency, lead time for changes, mean time to recovery, and change failure rate as signals for platform success. But it goes further — it insists platform teams also instrument queue time and activity time for platform requests. Queue time (how long a request waits before work begins) is a direct measure of developer friction; activity time (how long work actually takes once someone starts it) exposes hidden slogs inside platform workflows. If your team still trots out “tickets closed” or “stories delivered” to justify the platform budget, you’re optimizing the wrong thing.
Second: ship a Minimum Viable Platform and curate golden paths. The guidance is explicit: start narrow, prove ROI, iterate. That means shipping opinionated, well-documented scaffolder templates and workflows that solve a small set of high-value problems, instrumenting their use, and showing measurable lift to product teams. The report explicitly warns about golden cages — platforms that lock teams into brittle tooling or one-size-fits-all policies. The right move is opinionated defaults with escape hatches and clear costs for opting out.
Third: the IDP UI is the new control plane. Backstage and portal-focused work in the ecosystem are converging on one role: the DevEx surface that exposes self-service, audit trails, and telemetry. Recent Backstage plugin activity — catalog integrations, scaffolder templates, and audit widgets — is not a quaint ecosystem detail. It’s the plumbing platform teams need to make their golden paths discoverable and auditable. Embed the audit trail in the portal UI; surface queue-time metrics next to templates; make the path to escalation a one-click, well-instrumented flow.
There’s a practical security and compliance implication here. If your platform provides automated remediation, template scaffolds, or CI/CD pipelines, the IDP UI must show an immutable audit trail: who triggered what, what template version executed, and which identity or service account was used. That is how you build trust with developer teams and with security reviewers — not with ad-hoc emails or ticket links.
A few ecosystem-level takeaways follow from these shifts. PlatformEngineering.org’s recent overviews note the landscape is fragmenting: infra, DevEx, data, security, AI, and observability platform teams increasingly act as independent products. That’s necessary. Each domain has different consumers and failure modes, and trying to fold them into a single monolithic platform is the fastest route to useless plumbing. But fragmentation raises governance questions: catalog contract versions, cross-platform SLAs, and shared telemetry standards become real engineering problems.
Opinion: this is overdue and the right call. Platform teams that continue to hide behind operational metrics — ticket counts, PR throughput, or lines of Terraform — will lose credibility. The conversation has moved: platform teams must show impact on developer velocity and reliability, and they must make that impact visible in the developer portal. If you build a platform without queue-time telemetry or without embedding auditability into the portal, you’ve built a fancy wrapper around ticket hell.
Here’s the pragmatic next step for platform leads: pick one high-value workflow, turn it into a Backstage-scaffolded golden path, instrument deployment frequency, lead time, change failure rate, and queue time, and present those trends to product leadership in the next quarterly review. If you can show fewer support handoffs and faster lead time for a single product line, you’ve earned the right to expand.
Final thought: we’re past the ideology phase. Platform engineering is entering the age of measurable products and observable developer experience. Teams that treat the IDP as a product — with telemetry, UX, and a documented roadmap — will be the ones who stop firefighting and start shaping how engineering actually ships code.
Sources
- New platform engineering research report | Google Cloud Blog
- 247 - Why Your Platform Engineering Is Failing (And How to Fix It) | Tech Lead Journal
- Platform Engineering in 2025: Still Stuck in Ticket Hell? | Equal Experts (YouTube)
- Platform Engineering Blog | PlatformEngineering.org
- Platform Weekly newsletter