By 2026, 80% of Orgs Will Have Platform Engineering Teams - But 70% Will Fail

General
1

In 2023, Gartner made a bold prediction: by 2026, 80% of large software engineering organizations would establish platform engineering teams — nearly doubling from 45% in 2022. We’re now in 2026, and the data confirms adoption is on track. But here’s the part nobody wants to talk about: up to 70% of those platform teams will fail to deliver meaningful impact, and nearly half will be disbanded or restructured within 18 months.

I’m sharing this because I’m living it. I’m scaling an engineering org from 25 to 80+ engineers at an EdTech startup, and standing up our platform team has been one of the hardest things I’ve done in 16 years of engineering leadership.

The Adoption Wave Is Real

The numbers are undeniable:

  • 80% of large orgs now have or are building platform engineering teams (Gartner)
  • 88% of executives view platform engineering as a key driver of high performance
  • 55% adoption across all org sizes by mid-2025, with 92% of CIOs planning AI integrations
  • The platform engineering market is projected to grow from $7.2B (2024) to over $40B by 2032

Platform engineering isn’t a trend anymore. It’s becoming table stakes. But adoption and success are very different things.

Why 70% Fail

After talking to dozens of engineering leaders and studying the data, I see the same failure patterns over and over:

1. Building Without Listening

The number one killer is platform teams that build what they think developers need without actually asking. Most platform teams are staffed with infrastructure engineers who assume they understand developer workflows. They build impressive architectures that nobody uses.

The fix: Treat your platform as a product and your developers as customers. Run discovery interviews. Shadow developers during their onboarding. Measure adoption, not deployment.

2. The Backstage Trap

Spotify’s Backstage has ~89% market share in developer portals. Spotify themselves report 99% voluntary adoption across 14,000+ services. The problem? Organizations outside Spotify average roughly 10% internal adoption. Teams spend 6-12 months on setup, then discover the maintenance burden consumes all their capacity. They never get to building the unique capabilities their developers actually need.

The lesson isn’t “don’t use Backstage.” It’s that a developer portal is not a platform. The portal is the storefront — the platform is the warehouse, logistics, and supply chain behind it.

3. Mandated Paths vs Golden Paths

There’s a critical difference between mandating a single way to do things and offering a “golden path” — a supported, standardized, low-friction default that developers choose because it’s the easiest option. The best platforms make the right thing the easy thing. The worst platforms make the only thing the mandated thing.

At my company, we learned this the hard way. Our first platform iteration required developers to go through our provisioning system for everything. Adoption was maybe 30%. When we redesigned it as opt-in golden paths with the ability to deviate when needed, adoption jumped to 75% within two months.

What Success Actually Looks Like

When platform engineering works, the results are transformative:

  • Spotify: 40% cognitive load reduction across engineering
  • Netflix: 85% self-service rate, 10-minute average deployments, 90% reduction in support tickets
  • Gartner benchmarks: 30-40% improvement in developer satisfaction, 50% reduction in onboarding time, 70% less time spent on infrastructure setup

At my org, we measure three things:

  1. Developer NPS — quarterly surveys asking engineers to rate the platform team
  2. Self-service ratio — percentage of infrastructure requests that don’t need a ticket
  3. Time to first deploy — how quickly a new engineer can ship to production

We went from a 14-day average time-to-first-deploy to 3 days after launching our IDP. That’s the metric that got leadership to double our platform team’s headcount.

The Platform-as-Product Mindset

The single most important lesson I’ve learned: your platform team needs a product manager. Not an engineering manager who also does product work. An actual PM whose job is to understand developer needs, prioritize the roadmap, and measure adoption.

We hired a PM for our platform team six months ago. She runs bi-weekly “developer office hours,” maintains a public roadmap, and tracks feature adoption rates the same way our product PMs track user engagement. It changed everything.

What’s Coming Next

The next wave is AI-enhanced IDPs. Platforms that offer context-aware recommendations, enforce policy-as-code, generate environment previews, and integrate AI assistants directly into developer workflows. 92% of CIOs are planning AI integrations into their platforms. The platforms that succeed in 2026-2027 will be the ones that reduce cognitive load through intelligence, not just standardization.

The Questions I’m Wrestling With

For those of you building or consuming internal platforms:

  1. How are you measuring platform team success? Developer NPS? Ticket reduction? Something else?
  2. Did you start with a portal (Backstage, Port, Cortex) or with golden paths and self-service tooling?
  3. How do you handle the political dynamics of a platform team that serves but doesn’t own the product roadmap?

I’d love to hear both success stories and cautionary tales. The 70% failure rate means most of us are going to get this wrong at least once. :light_bulb:

2

Keisha, the “portal is the storefront, not the platform” framing is perfect. I’ve been on both sides of this — building platforms at Google Cloud and now consuming them at a startup — and the gap between what platform teams ship and what developers actually need is consistently the biggest problem.

The DevOps → Platform Engineering Evolution

I’ve lived through this transition. At Google, we didn’t call it “platform engineering” — we called it “developer infrastructure” — but the concept was the same: a dedicated team building self-service tooling so product engineers didn’t have to think about Borg (Google’s cluster management), networking, or monitoring configuration. It worked because Google had 20 years of iteration and a culture where infra teams were respected as product teams.

The problem is that most companies try to copy the output (“let’s build an IDP!”) without copying the culture (“let’s treat developers as customers with real needs and real alternatives”).

The Backstage Reality Check

I want to push back slightly on the Backstage narrative, because I think the 10% adoption number is misleading without context. Backstage is a framework, not a product. It’s like comparing Rails adoption to Shopify adoption. Spotify built years of custom plugins on top of Backstage that are specific to their workflows. When other orgs deploy vanilla Backstage and wonder why nobody uses it, that’s not a Backstage failure — it’s a product strategy failure.

That said, the maintenance burden is real. I’ve seen teams where 2 of 3 platform engineers are doing Backstage plugin maintenance instead of building golden paths. Tools like Port and Cortex are gaining ground precisely because they’re opinionated products, not frameworks you have to assemble yourself.

What Golden Paths Look Like in Practice

For anyone wondering what a “golden path” actually looks like concretely:

At my current startup, our platform team provides:

  • A service template — run one CLI command, get a new service with CI/CD, monitoring, logging, and a staging environment pre-configured
  • A database provisioning workflow — request a Postgres or Redis instance through a Slack bot, get it in <5 minutes with backups and alerting configured
  • A deployment pipeline — push to main, it deploys to staging; merge a PR with the “deploy” label, it goes to production with canary rollout

None of this required a portal. We built the golden paths first, measured adoption, and we’re only now considering a portal to catalog everything.

AI-Enhanced IDPs Are the Real Next Step

The 92% CIO number for AI integration is what excites me most. Imagine an IDP that:

  • Suggests the right service template based on your PR description
  • Auto-detects when you’re reinventing something another team already built
  • Generates Terraform from natural language infrastructure requests
  • Reviews your Kubernetes manifests against organizational policies before apply

We’re prototyping some of this now with Claude and MCP. The early results are promising — our developers are spending roughly 40% less time on infrastructure configuration in the pilot group.

My recommendation for anyone starting: golden paths first, portal second, AI third. Each layer builds on the one before it. Skip to the portal without the paths and you’ll join the 70%.

3

Keisha, this hits close to home. I stood up a platform team at our Fortune 500 financial services company about 18 months ago, and we’ve been through almost every failure mode you described before finding something that works.

The “Two Pizza Team” That Became Eight Pizzas

We started with the classic two-pizza team: 4 infra engineers. Their mandate was broad — “improve developer experience.” Six months in, we had a beautifully designed Kubernetes operator, a custom GitOps pipeline, and a service mesh configuration that was genuinely impressive from an engineering standpoint.

Adoption? Maybe 15% of our engineering org. The rest kept doing things the old way because the old way worked for them, even if it was slower.

What we didn’t have was anyone who understood what developers actually wanted. We had four infrastructure engineers solving infrastructure problems, not developer problems. The distinction matters enormously.

The PM Hire Changed Everything

Keisha, I can’t emphasize enough how much I agree about the PM hire. Ours was the turning point.

Our platform PM’s first act was running a survey across all 40+ engineers asking one question: “What’s the most annoying thing about shipping code here?” The top three answers were:

  1. Environment setup — new engineers spent days configuring local and staging environments
  2. Secret management — rotating secrets was manual and error-prone
  3. Database migrations — no standard process, every team had a different approach

Not one of those was on our platform team’s original roadmap. They’d been building a service mesh while developers were fighting with environment variables. The PM reoriented the entire roadmap in two weeks, and within a month we had self-service environment provisioning. Adoption went from 15% to 60% overnight.

Measuring What Matters

To answer your question about metrics, we track:

  • DevOps ticket volume — down 42% since launching the IDP
  • Time to production for new hires — from 3 weeks to 4 days
  • Internal CSAT — quarterly survey, currently at 7.8/10 (started at 4.2)
  • Golden path adoption rate — 73% of new services use our templates

The metric I wish we’d tracked from day one: escape velocity — how long it takes a developer to stop needing help from the platform team. That’s the real measure of self-service.

The Political Reality at Scale

Here’s what nobody talks about in the blog posts: platform teams at large companies face brutal political dynamics. Your platform team serves everyone but owns nothing on the product roadmap. When leadership asks “what did the platform team deliver this quarter?” the answer is “we made other teams 30% faster” — and that’s a hard story to tell in a promotion committee.

We solved this by co-locating platform engineers with product squads on a rotating basis. Every quarter, one platform engineer spends 50% of their time embedded with a product team. They build relationships, understand real workflows, and bring back insights that shape the roadmap. It also means product teams have advocates for the platform inside their standups.

My Honest Assessment

18 months in, are we in the 30% that succeed or the 70% that fail? I’d say we’re in the messy middle. Our golden paths work well. Our portal is mediocre. Our AI integration is barely a prototype. But developer satisfaction is genuinely higher, and our time-to-production metrics are the best they’ve ever been.

The lesson for other directors: start with the developer’s pain, not the technology. And for the love of all that is good, hire a PM before you write a single line of platform code. :folded_hands:

4

I want to offer the perspective that’s often missing from these conversations: the developer who’s supposed to be the “customer” of the platform team. Because I’ve been on the receiving end of three different internal platform initiatives across two companies, and I have opinions.

What Good Platform DX Looks Like

At TechFlow, our platform team got it right on the second try. Here’s what makes me actually want to use their tooling:

It meets me where I am. I don’t have to learn a new UI, navigate a portal, or context-switch to a different tool. Our service templates are GitHub repo templates. Our deployment config is a YAML file in my repo. Our environment provisioning is a Slack command. Everything integrates into tools I already use every day.

It doesn’t hide complexity — it manages it. I can see exactly what Terraform is being generated. I can inspect the Kubernetes manifests. If something goes wrong, I can debug it myself instead of filing a ticket and waiting. The golden path is transparent, not opaque.

The documentation is actually good. This sounds basic, but I’ve used platforms where the only docs were a Confluence page last updated 8 months ago with screenshots of a UI that no longer exists. Our platform team maintains a docs site that’s versioned alongside the platform code. If you change the platform, you change the docs in the same PR. Non-negotiable.

The Self-Service Gap

Here’s my biggest frustration with platform teams that claim to offer “self-service”: most of them are just prettier ticket systems.

“Self-service” that requires me to:

  1. Go to a portal
  2. Fill out a form with 15 fields
  3. Wait for an approval workflow
  4. Get a Slack notification 2 hours later

…is not self-service. It’s a ticket system with a React frontend.

Real self-service means I can run a command, and the thing exists. If it needs approval, the approval should be policy-as-code that evaluates instantly, not a human in the loop for every request. The only time a human should be involved is when I’m doing something genuinely unusual.

The Onboarding Impact Is Real

I want to validate Keisha’s time-to-first-deploy metric because I’ve experienced it from the other side. When I joined TechFlow, the platform team’s onboarding golden path had me:

  • Day 1: Laptop setup via a single script, access provisioned automatically
  • Day 2: First PR opened against a real codebase using a guided tutorial
  • Day 3: First deployment to staging
  • Day 4: First production deployment (a small config change, but still — production on day 4!)

Compare that to my previous company where it took me three weeks to get my development environment working, and another week before I could deploy anything. The difference in how valued and productive I felt was massive.

What I Wish Platform Teams Knew

Three things I want every platform engineer to hear from their users:

  1. Don’t deprecate things without a migration path. Nothing destroys trust faster than “we’re sunsetting X next month, please migrate to Y” when Y doesn’t have feature parity. Give us an overlap period and automated migration tools, or don’t deprecate.

  2. Catalog decay kills adoption. If your service catalog shows 40 services but 15 of them are abandoned, I stop trusting the catalog entirely. Stale data is worse than no data because it trains me to ignore your platform.

  3. Talk to us, not about us. The best platform teams I’ve worked with run monthly “office hours” and actually implement the feedback. The worst ones present their roadmap at all-hands and ask “any questions?” Those are very different forms of engagement.

The 70% failure rate doesn’t surprise me at all. What surprises me is that the 30% who succeed all seem to do the same thing: they listen to developers first and build technology second.