The head of platform engineering at a Fortune 500 retailer pulled up their Internal Developer Portal dashboard during our call. It was impressive: service catalog, environment provisioning, deployment pipelines, cost visibility, golden paths for Java and Python services. They'd spent 14 months and $2.3 million building it.
"So what's the adoption rate?" I asked.
He hesitated. "About 23% of developers are using it regularly."
"And the other 77%?"
"They're still opening Jira tickets to the DevOps team. Or worse, going around us entirely—spinning up resources directly in AWS, deploying through custom scripts, managing their own infrastructure."
This isn't a technology failure. It's a pattern I see everywhere. Organizations are investing millions in platform engineering but building platforms developers don't want to use. The infrastructure is modern. The developer experience is stuck in 2019.
IDC's Platform Engineering and DevOps Survey shows 93% of organizations are piloting, using, expanding, or planning to use an IDP within the next year. Yet Jellyfish research across 200,000 engineers reveals a stark gap: organizations with the highest platform adoption maturity see 2x PR throughput compared to those in early stages. The difference isn't the platform—it's how it's built.
The Self-Service Illusion
Platform engineering promised to solve the DevOps bottleneck. Instead of every engineering team waiting on an overloaded DevOps group for infrastructure, they'd get self-service capabilities through a polished portal. Platform teams would build golden paths. Developers would move faster. Operations would maintain control.
The theory is sound. The execution is failing for four predictable reasons:
1. The Platform Team Built for Operations, Not Developers
Most IDPs are designed from the platform team's perspective. They solve platform team problems: standardization, compliance visibility, cost tracking, access control. These matter, but they're not why developers show up to work in the morning.
Developers want to ship code. They want fast feedback loops. They want to understand why their deployment failed without reading 400 lines of Terraform output. They want to provision a database in minutes, not hours. They want to debug production issues without learning three different observability tools.
When the IDP makes compliance easy but debugging hard, developers route around it. When the golden path handles 80% of use cases beautifully but leaves the remaining 20% completely unsupported, developers abandon the path entirely. When provisioning a service requires filling out five forms and waiting for approval workflows, developers find faster ways.
The platform team sees non-compliance. The developers see a tool that doesn't understand their job.
2. The Abstraction Gap
Platform engineering's core promise is abstraction: hide infrastructure complexity so developers can focus on applications. But abstractions leak, and when they do, developers need to understand the underlying systems anyway.
I worked with a company whose IDP abstracted Kubernetes entirely. Developers deployed "services" without knowing what a pod, deployment, or service was. It worked great—until it didn't. When applications started crashing under load, developers couldn't debug because they didn't understand resource limits, HPA settings, or pod disruption budgets. They'd built an abstraction so complete that their users were helpless when it failed.
Effective platforms provide progressive disclosure. They make the easy path truly easy while preserving escape hatches for complex scenarios. They don't hide complexity—they manage it intelligently, revealing details when developers need them and hiding them when they don't.
3. The Migration Mirage
Organizations often treat platform adoption as a migration project: "We'll move all services to the new platform by Q3." This approach almost always fails.
Developers have jobs to do. They have features to ship, bugs to fix, deadlines to meet. Asking them to pause productive work to migrate to a new platform—especially one that might not work as promised—is a tough sell. When the migration conflicts with sprint commitments, the migration loses.
The platform teams that succeed don't run migration projects. They run adoption programs. They identify teams with acute pain points and make the platform irresistibly better than the status quo. They let developers opt-in because the value is obvious, not because they're forced. Organic adoption always beats mandated migration.
4. The Support Vacuum
Platform teams often operate with a "build it and they will come" mentality. They launch the portal, announce it in Slack, write documentation, and move on to the next feature.
But developers need support. They encounter edge cases the platform team never considered. They hit errors that don't match the documentation. They need help understanding which golden path applies to their use case. When that support doesn't exist—when Slack messages go unanswered, when documentation is incomplete, when there's no one to pair with—developers conclude the platform isn't ready and revert to familiar patterns.
Companies with successful platform teams invest heavily in developer success: dedicated support channels, office hours, pairing sessions, and rapid response to feedback. The platform isn't just software—it's a service, and services require ongoing investment.
The Cost of Platform Failure
When IDPs fail to gain adoption, organizations pay a price measured in more than just wasted infrastructure investment:
Operational chaos increases. Developers creating resources outside the platform leads to shadow infrastructure—untracked, ungoverned, often insecure. The platform team can't optimize what they can't see. Cost optimization becomes impossible when 40% of infrastructure exists outside the system.
Developer velocity stalls. Companies adopting self-service IDPs report a 50% reduction in operational tickets related to resource requests. When developers bypass the platform, they go back to opening tickets. Platform teams become bottlenecks again. Everyone waits.
Security and compliance gaps widen. The whole point of golden paths is ensuring security and compliance by default. When developers work outside the platform, they work outside the guardrails. Every manual AWS console session is a potential security incident. Every custom deployment script is technical debt that will eventually break.
Engineering culture deteriorates. Developers resent being forced into tools that make their jobs harder. Platform teams resent building tools no one uses. The relationship becomes adversarial instead of collaborative. The platform team sees developers as non-compliant. Developers see the platform team as out of touch. Neither side is wrong—and neither side is winning.
Gartner predicts 95% of new digital workloads will be deployed on cloud-native platforms by 2026—up from just 30% in 2021. With 48% of enterprises maintaining hybrid deployments spanning cloud and on-premises, and the average enterprise now running 6.3 Kubernetes clusters in production, the complexity that platform engineering must manage is unprecedented. Without effective platforms, this complexity becomes unmanageable.
The Product Mindset Shift
The organizations that succeed with platform engineering treat their platforms as products, not infrastructure projects. This shift changes everything.
They have product managers. Someone owns the developer experience, understands user needs, prioritizes the roadmap based on value delivered, and says no to features that don't serve the core use case.
They measure adoption actively. Not just "how many services are on the platform" but "what percentage of developers used the platform this week," "how long does it take a new developer to deploy their first service," and "what's our Net Promoter Score among platform users."
They optimize for time-to-value. The best platforms get developers productive in hours, not weeks. They require minimal onboarding. They provide templates that work out of the box. They optimize for the first deployment experience, knowing that developers who succeed early become advocates.
They treat documentation as a feature. Not an afterthought—a core product component. Documentation is tested, updated, and validated. It includes working examples, not just reference material. It anticipates the questions developers actually ask.
The 90-Day Platform Recovery Framework
If your IDP is struggling with adoption, you don't need to rebuild from scratch. You need to change how you think about the platform and how you engage with your users. Here's the framework I use with platform teams that are ready to turn things around:
Days 1-30: Understand Your Users
Stop building for a week. Start listening. Interview developers who aren't using the platform. What are they doing instead? Where does the current platform fall short? What would make them switch?
Shadow developers doing their actual work. Watch them provision infrastructure, deploy applications, debug production issues. Don't ask them to explain—watch them do it. You'll discover pain points they can't articulate.
Map the developer journey from "I have an idea" to "it's running in production." Identify every friction point, every context switch, every handoff. These are your optimization targets.
Days 31-60: Fix the Top Three Frictions
Pick the three highest-friction moments from your research. These are your quick wins. Common targets: reduce service provisioning from hours to minutes, provide clear error messages when deployments fail, create debugging workflows that don't require platform team intervention.
Implement progressive disclosure. Make the golden path truly golden—fast, reliable, well-documented—but preserve escape hatches for edge cases. Developers should never feel trapped by your abstractions.
Establish a developer success function. Dedicate someone to onboarding, support, and feedback collection. This isn't optional—it's as important as any engineering investment. Developers need to know help is available when they need it.
Days 61-90: Drive Organic Adoption
Identify two teams with acute platform pain—maybe they're waiting weeks for infrastructure, or managing complex deployments manually. Make them your design partners. Solve their specific problems. Make them heroes.
Measure and publish your metrics. Track adoption rates, time-to-first-deployment, support ticket resolution times, and developer satisfaction scores. Make the platform's value visible to leadership and the engineering organization.
Create a feedback loop that actually loops. Weekly office hours, a public roadmap, visible responses to feature requests. Developers need to see that their input matters. Platforms built in isolation fail. Platforms built with users succeed.
What Winning Looks Like
A SaaS company I worked with was struggling with exactly this problem. Their platform team had built a comprehensive IDP on top of Kubernetes, but adoption stalled at 30%. Developers complained it was "too restrictive," "hard to debug," and "slower than just doing it myself."
We spent 30 days understanding developer workflows. The findings were humbling: provisioning a database through the platform took 45 minutes and three approval workflows. Debugging a failed deployment required reading raw Kubernetes events. There was no local development environment that matched production.
The platform team pivoted. They didn't add features—they fixed fundamentals. Database provisioning became self-service with guardrails, not gates. Deployment failures generated human-readable error messages with remediation steps. They invested in a local development tool that mirrored production.
Six months later:
- Platform adoption: 30% → 89%
- Time to provision infrastructure: 45 minutes → 3 minutes
- Operational tickets: Down 67%
- Developer satisfaction (internal NPS): +42 points
- Production incidents caused by misconfiguration: Down 78%
The platform didn't change technically—Kubernetes, Terraform, ArgoCD all stayed the same. What changed was the developer experience. The platform team stopped building what they thought developers needed and started building what developers actually asked for.
"The best platform teams don't dictate how developers should work. They understand how developers do work and remove the friction from those workflows. Platform engineering isn't about control—it's about enablement."
The AI Workload Factor
There's another pressure driving platform engineering adoption: AI workloads. According to the CNCF Annual Cloud Native Survey, Kubernetes is now the de facto operating system for AI, with production usage reaching 82% in 2025. AI infrastructure is complex—GPUs, specialized schedulers, model serving frameworks, vector databases—and most developers can't manage it manually.
This creates both opportunity and risk for platform teams. The opportunity: developers desperately need platforms to manage AI infrastructure complexity. The risk: if platforms make AI workloads harder instead of easier, developers will route around them—and AI infrastructure is expensive enough that shadow resources can blow budgets fast.
Organizations with effective platform engineering are creating AI-specific golden paths that abstract GPU management, model deployment, and inference scaling. Organizations without effective platforms are watching their AI infrastructure costs spiral while their developers struggle with complexity that should be handled centrally.
The Path Forward
Platform engineering isn't failing as a discipline. It's failing in execution. Too many teams are building platforms they would want, not platforms their developers need. Too many organizations are treating adoption as a migration to mandate rather than a value proposition to sell.
The good news: this is fixable. The organizations that treat platform engineering as product development—user research, iterative improvement, active support, metrics-driven optimization—are seeing the returns that justified the investment in the first place. Organizations with the highest platform maturity see 2x PR throughput. Companies with self-service platforms report 50% fewer operational tickets. The value is real.
But the value only materializes when developers actually use the platform. That requires shifting from an infrastructure mindset to a product mindset. From "we built it, they should come" to "we're building what they need." From controlling developers to empowering them.
The platform engineering trap is real. But it's not a technology trap—it's a thinking trap. And thinking can change.
Your platform is a product. Your developers are customers. Start treating them that way.
Want help building a platform your developers actually use?