Gartner: 78% of large orgs have platform teams, on track for 80% by end of 2026. Backstage has 89% market share. The shift from DevOps to platforms.
Get new posts delivered to your inbox. No spam, unsubscribe anytime.
I watched a senior backend engineer spend three days last month trying to configure Kubernetes network policies for a new service. She's brilliant. She writes code that processes millions of transactions. But she was fighting YAML, not solving business problems. That's 75% of developers losing over 6 hours weekly to tool fragmentation — and it's why "you build it, you run it" is dying.
Gartner predicted that 80% of large software engineering organizations would establish platform engineering teams by 2026. As of early 2026, they're at 78%. The prediction is on track. The market has grown from $5.76 billion in 2025 to a projected $47.32 billion by 2035 at 23.4% CAGR. Platform engineering isn't a trend. It's the operating model that replaced DevOps.
DevOps didn't fail. It succeeded — and then it collapsed under its own success.
The original DevOps promise was simple: tear down the wall between development and operations. Developers should understand production. Operations should understand code. "You build it, you run it."
But here's what "you build it, you run it" morphed into in practice: "you build it, configure Kubernetes, manage CI/CD pipelines, debug infrastructure, handle compliance, and somewhere in there, run it." Every developer became a part-time infrastructure engineer. Microservices, multi-cloud, and compliance requirements multiplied cognitive load exponentially.
Platform engineering is DevOps evolved — from shared responsibility to explicit ownership, from culture to structure, from "everyone does everything" to "specialists build platforms that make the right thing easy."
The shift isn't from DevOps values. It's from DevOps as an organizing principle to platform engineering as an operating model. The values (automation, collaboration, fast feedback) survived. The implementation (every developer manages their own infrastructure) didn't.
Think of it this way: DevOps said "shifting left" — push responsibility toward developers. Platform engineering says "shifting down" — push complexity into an abstraction layer so developers don't have to think about it. The developer still deploys to production. They just don't have to write Kubernetes manifests to do it.
A mature platform looks like this from the developer's perspective: they push code to main, a CI pipeline runs tests, a deployment pipeline applies the changes, monitoring dashboards update automatically, and alerts page the right team if something breaks. The developer never touches kubectl. They never edit a Helm chart. They never configure an ingress. All of that exists — it's just hidden behind the platform.
That's not DevOps dying. That's DevOps being implemented correctly. The irony is that platform engineering delivers the DevOps promise better than DevOps ever did.
78% of large enterprise DevOps teams now have a dedicated platform engineering function. 75% of platform teams provide self-service developer portals. Over 60% are building or planning AI-assisted features.
But here's the uncomfortable stat: only 25% of organizations with platform engineering teams rate their platform as "mature." The largest cohort (45.5%) operates dedicated, budgeted teams that remain primarily reactive. Only 13.1% have achieved optimized, cross-functional ecosystems.
The productivity gains are real where platforms are done right:
A 25-person team case study showed $2.76 million per year in annual benefits: $390K in toil reduction, $1.56M in AI-augmented productivity, $468K in incident response savings, and $337K in faster time-to-market.
The DX Developer Experience Index provides a useful measurement framework. Each 1-point DXI improvement saves 13 minutes per developer per week — 10 hours annually. At 100 developers, that's roughly $100K per year in recovered productivity. Platform improvements typically show results within 6-12 weeks of MVP deployment, though comprehensive ROI measurement requires 6-12 months of adoption data.
The math is straightforward: if your 200-person engineering org spends an average of 6 hours per week on infrastructure toil (Kubernetes, CI/CD, monitoring setup), that's 1,200 hours per week of engineering time not spent on product work. At an average cost of $100/hour, that's $6.24 million per year in toil. A platform team of 8 people costing $2 million per year that reduces toil by 50% saves $1.12 million annually — and that doesn't include the productivity gains from faster deployment cycles and fewer incidents.
Backstage, Spotify's open-source developer portal, has 89% market share among IDP frameworks. 3,400+ adopters, 2 million+ developers served outside Spotify, 1,600 contributors. It's ranked 6th among 230+ CNCF projects by community velocity.
The adopter list reads like a tech directory: Airbnb, Booking.com, H&M, LEGO, Netflix, Philips, OVO Energy.
But Backstage isn't a product — it's a framework. It requires significant engineering investment to deploy. You need to build plugins, configure authentication, integrate with your specific infrastructure, and maintain it as an internal product. That's the right trade-off for large organizations that need full control. It's the wrong trade-off for teams that want a portal running by Friday.
The commercial alternatives trade customizability for speed:
| Tool | Approach | Best For | Trade-off |
|---|---|---|---|
| Backstage | Open-source framework, 230+ plugins | Large orgs wanting full control | Months of setup |
| Port | Commercial portal, built-in scorecards | Fast deployment (days) | Pricing scales with users |
| Humanitec | Platform orchestrator, "Score" spec | Standardizing deployments | Not a portal — an engine |
| Kratix | K8s-native, "Promise-based" delivery | K8s-heavy organizations | Requires significant customization |
The distinction matters: Backstage and Port are developer portals (UI for discovery and self-service). Humanitec is a platform orchestrator (engine for infrastructure automation). Kratix is a framework for building platform APIs. You might use Backstage as the frontend and Humanitec as the backend.
The open-source vs. commercial decision depends on your team size and timeline. Open-source tools (Backstage, Crossplane, Kratix) give full control but require engineering investment — plan for 3-6 months to get a usable Backstage instance. Commercial platforms (Port, Cortex, Humanitec) cost money but deliver value in days, not months. Most organizations above 200 engineers end up with Backstage. Most below 100 start with a commercial option.
This is the concept that separates successful platforms from expensive failures.
A golden path is a pre-configured, opinionated template guiding developers through common tasks: deploying a new service, setting up a database, configuring monitoring. It includes standard deployment patterns, approved tech stacks, and pre-configured security settings.
The adoption data is stark. Teams that invest in well-designed golden paths see voluntary adoption rates above 80%. Teams that skip golden paths struggle to reach 20%. And 70% of platform initiatives fail to achieve meaningful adoption — golden paths are the primary differentiator.
The key principle: golden paths are optional, not mandatory. Developers get escape hatches for edge cases. The goal isn't to restrict — it's to make the common case effortless.
# golden-path/new-service/template.yaml
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
name: new-microservice
title: Create a New Microservice
spec:
parameters:
- title: Service Info
properties:
name:
type: string
language:
type: string
enum: [typescript, python, go]
database:
type: string
enum: [postgresql, none]
steps:
- id: scaffold
action: fetch:template
input:
url: ./skeleton
- id: create-repo
action: github:repo:create
- id: setup-ci
action: github:actions:dispatch
- id: register
action: catalog:register
One click. The developer gets a new GitHub repo, CI/CD pipeline, Kubernetes manifests, monitoring dashboards, and a service catalog entry. The golden path encodes every infrastructure decision the platform team has made — and the developer never has to think about any of them.
45.3% cite developer adoption as their top challenge. Not technical complexity. Cultural resistance. And 47.4% of platform initiatives operate on budgets under $1M while expected to deliver broad organizational impact.
The five most common antipatterns from Jellyfish's research:
1. Over-Engineering ("Perfection Loop"). Building a platform that handles every conceivable use case before shipping anything. The fix: solve the 80% use case first. Provide escape hatches for the 20%.
2. TicketOps. Replacing self-service with ticket queues. If developers still need to file a Jira ticket to get a database, your platform isn't a platform — it's a help desk with a fancy name.
3. Templates-as-a-Service. Over-reliance on rigid templates that rot as infrastructure evolves. Templates need active maintenance like any other code. Dead templates are worse than no templates because developers follow them into deprecated infrastructure patterns and security vulnerabilities. Treat templates like production code: test them, version them, deprecate them with clear migration paths.
4. Building Without Executive Buy-in. Without top-down support, platforms become "expensive monuments to engineering excellence that deliver zero business value."
5. No Measurement. Nearly 30% of platform initiatives don't measure success at all. Without metrics, you can't demonstrate ROI or secure continued investment. A platform with 100 features and 10 users is a failure. A platform with 5 features and 5,000 users is a triumph.
Platform teams should stay small and split when growing beyond 8-10 members or when the mission becomes too broad.
The critical roles:
The required skills are evolving. In 2026, platform engineers increasingly need familiarity with AI agent tooling and GPU workload management. 94% of organizations view AI integration in platforms as critical or important.
The soft skills matter as much as the technical ones: empathy, partnership, patience. You're building a product for people who didn't ask for it and may actively resist using it. That requires product thinking, not just infrastructure thinking.
The CNCF published a platform engineering maturity model with five levels: Learn, Crawl, Walk, Run, Fly. It assesses five dimensions: Investment, Adoption, Interfaces, Operations, and Measurement.
The reality check: each additional maturity level requires greater funding and headcount. Reaching the highest level isn't a goal in itself. Most organizations should target "Walk" or "Run" — where the platform provides self-service capabilities with good measurement and moderate team investment.
Here's what each level looks like in practice:
The jump from Crawl to Walk is where most organizations get stuck. It requires executive buy-in, dedicated budget, and a product manager — not just enthusiastic engineers working on platform tooling between feature sprints.
Platform engineers earn the highest average salary among cloud-native roles at $172,038 — approximately 20% higher than DevOps roles.
| Metric | Value |
|---|---|
| Average total comp (Glassdoor) | $214,936 |
| 90th percentile | $340,973 |
| 25th-75th range | $170,744 - $275,389 |
| Senior platform engineer avg | $241,465 |
| Base salary (Indeed) | $157,847 |
The market is democratizing. 2024 was dominated by senior early adopters commanding premium compensation. 2025-2026 is opening up to mid-level engineers with 3-7 years of experience. If you're a DevOps engineer looking at the job market, "platform engineer" is where the growth is.
Week 1-2: Discovery. Interview 10 developers. Ask them: "What's the most annoying thing about deploying a new service?" and "How much time do you spend on infrastructure tasks per week?" Document the top 5 pain points. You'll be surprised — they're rarely what the infrastructure team thinks they are.
Week 3-4: Quick Win. Pick the single most painful developer workflow and automate it. If it's "creating a new service requires 8 manual steps," turn those 8 steps into a GitHub Actions workflow or a script. Ship it. Get adoption data.
Month 2-3: Golden Path MVP. Build one golden path for your most common use case (probably "deploy a new API service"). Include the repo scaffold, CI/CD pipeline, Kubernetes manifests, and monitoring. Make it a Backstage template or a simple CLI tool.
Month 3-6: Portal. Stand up Backstage (or Port if you want faster time-to-value). Populate the service catalog. Add the golden path you built. Measure adoption weekly. If developers aren't using it, the platform doesn't solve a real problem.
Month 6-12: Scale and Measure. Add golden paths based on developer requests. Implement DX metrics. Track DORA metrics. Present quarterly ROI to leadership. By month 12, you should know whether the platform is saving enough developer time to justify its existence.
The mistake most teams make: they spend 6 months building infrastructure before shipping anything to developers. Ship early, ship often, measure everything. Platform engineering is product development — and product development requires fast feedback loops.
Platform engineering didn't kill DevOps. It revealed that DevOps was always a cultural movement pretending to be an engineering discipline. The values were right. The implementation — expecting every developer to be a full-stack infrastructure expert — was wrong.
The best platform teams I've seen share three traits: they treat their platform as an internal product (with a PM, roadmap, and user research), they build golden paths that make the right thing easy (not mandatory), and they measure adoption (not features shipped).
The worst platform teams I've seen build elaborate infrastructure nobody uses. They optimize for technical elegance instead of developer experience. They create Backstage instances with 50 plugins and no golden paths. They replace ticket queues with slightly different ticket queues and call it "self-service."
Here's my actual advice for 2026: if your engineering org has fewer than 50 developers, you probably don't need a platform team. A well-maintained set of Terraform modules, GitHub Actions workflows, and a README is enough. Platform engineering adds value at scale — when the cost of every developer managing their own infrastructure exceeds the cost of a dedicated team abstracting it away.
The $47 billion market projection by 2035 sounds aggressive, but I actually think it's conservative. Every engineering organization above 100 people will need platform engineering. Every one. The question isn't whether to invest. It's whether to invest now (while the talent pool is growing and best practices are emerging) or later (when your competitors have already captured the productivity gains).
If you do build a platform team, hire the product manager first. Not the Kubernetes expert. Not the Backstage contributor. The person who will sit with developers, understand their pain, and ruthlessly prioritize the 5 things that eliminate the most friction — not the 50 things that would be technically interesting.
The 78% adoption number is real. But so is the 25% maturity number. Most organizations have a platform team. Most of those teams haven't yet built a platform worth using. The gap between "having a platform team" and "having an effective platform" is where the hard work lives. And it's mostly product work, not infrastructure work.
One thing I keep coming back to: the salary premium tells the real story. Platform engineers earn 20% more than DevOps engineers on average. That premium exists because the role is harder — you need infrastructure depth, product thinking, empathy for developers, and the patience to build something that might take 12 months to prove its value. That's a rare combination. DevOps was "developers who also do ops." Platform engineering is "infrastructure engineers who think like product managers." The bar is higher, which is why the pay is higher, and why so many organizations struggle to hire for the role.
If I had one piece of advice for someone building a platform team in 2026: measure developer satisfaction, not platform features. Every month, survey your developers. Are they spending less time on infrastructure? Can they deploy faster? Do they understand the golden paths? If those numbers aren't improving, nothing else matters. Features don't matter. Architecture doesn't matter. The only metric that matters is whether developers can ship product code faster because your platform exists.
The 70% failure rate for platform initiatives isn't because the technology is wrong. It's because the approach is wrong. Platform engineering is the hardest kind of engineering — building a product for a customer base (your developers) that already has strong opinions, existing workflows, and zero patience for tools that make their lives harder instead of easier. Treat it like a startup: find product-market fit first, scale second.