I just finished reading the latest platform engineering maturity report, and one stat stopped me cold: 90% of enterprises now have internal developer platforms, beating Gartner’s prediction by a wide margin.
That sounds like a massive success story, right?
Except here’s the uncomfortable follow-up: 45% of platform teams still struggle with developer adoption.
At my Fortune 500 financial services company, we scaled our platform team from 3 engineers to 12 over the past 18 months. We built self-service provisioning, standardized deployment pipelines, comprehensive observability, the works. Our metrics looked great: 40% faster deployments, 60% fewer production incidents.
But adoption plateaued at 35%.
Not because developers didn’t know about the platform—we had docs, demos, office hours, Slack channels. They knew. They just chose not to use it.
The Developer Feedback Was Brutal
When I finally sat down with engineers who weren’t adopting the platform, the feedback cut deep:
- “It solves problems I don’t have” - Backend team maintaining 3-year-old Java monolith
- “It’s slower than my current workflow” - Senior engineer who had her own Docker setup dialed in
- “I can’t customize it for my use case” - ML team needing GPUs and custom runtimes
- “Nobody asked us what we actually needed” - Pretty much everyone
That last one hit hardest. We’d spent 18 months building infrastructure we thought developers wanted. Turns out we were building for an idealized developer that didn’t exist in our org.
The Real Problem: Infrastructure Thinking vs Product Thinking
I think the 45% adoption struggle exists because most platform teams (mine included) are still thinking like infrastructure engineers, not product managers.
We optimize for:
- Technical excellence
- Standardization
- Compliance
- Cost efficiency
Developers want:
- Speed
- Flexibility
- Reduced friction
- Autonomy
These aren’t always the same thing. A “golden path” that enforces standards feels like handcuffs to a senior engineer who knows exactly what she needs.
The Questions I’m Wrestling With
-
Is 45% struggling with adoption the canary in the coal mine? Are we building platforms because it’s trendy, not because developers are pulling for them?
-
When does “low adoption” mean “wrong platform” vs “wrong communication”? How do you know if you should pivot your platform vs just market it better?
-
Should platforms be optional or mandated? Our leadership wants to mandate the platform for all new services. I’m worried that’ll breed resentment and shadow IT.
-
How do you measure developer outcomes, not just platform outputs? We track platform uptime and deployment frequency. But are developers actually more productive? I don’t know.
-
Is the AI era about to make this whole conversation obsolete? If developers can describe what they need and AI translates it to infrastructure, does the “golden path” even matter?
What I’m Trying Next
We’re running a reset:
- JTBD interviews with every engineering team to understand their actual workflows
- Tiered approach: Fully managed for teams that want it, configurable for teams that need it, custom for teams that demand it
- Measuring adoption differently: Not “how many teams use the platform” but “how many teams would choose it if alternatives existed”
- Platform PM hire: Someone whose job is developer adoption, not infrastructure uptime
But I’m not confident this will work. Because maybe the real answer is that we built something impressive that nobody needed.
For those of you running platform teams: What’s your actual adoption rate? How do you know if developers are using your platform because it’s good or because they have no choice?
For those of you who are developers: Would you use your company’s platform if it were optional? Why or why not?
I’m genuinely curious if the 45% adoption struggle is an industry-wide problem or if my team just missed the mark.