45.3% Say Developer Adoption Is Their Top Platform Engineering Challenge—Are We Building Infrastructure Nobody Asked For?

diana_data · April 10, 2026, 5:19am

We just scaled our platform engineering team from 3 to 12 engineers over the last 18 months. On paper, everything looks amazing:

40% faster deployments across the organization
60% fewer production incidents since implementing our golden paths
Developer self-service for 90% of infrastructure needs

But here’s the uncomfortable truth: developer adoption plateaued at 35%.

I’m sitting in a board meeting last week, and our CEO asks: “If the platform is so good, why are only a third of developers using it?” I didn’t have a great answer.

The Data That’s Making Me Question Everything

I’ve been reading the 2026 platform engineering reports, and the numbers are revealing a pattern we don’t talk about enough:

45.3% cite developer adoption as their top challenge — not technical complexity, not tooling maturity, but getting developers to actually want to use the platform
36.6% rely on mandates to drive adoption — which means the other 63.4% understand that forcing adoption doesn’t work
29.6% don’t measure success at all — we’re building infrastructure without knowing if it creates value

The data suggests cultural resistance, not technical limitations, is the primary obstacle to platform engineering success.

Are We Just Centralizing DevOps Problems?

Here’s what I’m wrestling with: Did we solve DevOps friction at scale, or did we just centralize the problems?

DevOps friction we were trying to solve:

Developers drowning in infrastructure complexity
Every team solving the same problems differently
Inconsistent security and compliance approaches
Knowledge silos when teams built custom solutions

Platform engineering friction we created:

Friction between centralized platform team and developer autonomy
One-size-fits-all solutions that don’t fit anyone perfectly
Mandates vs. developer pull — when we measure infrastructure health instead of developer outcomes
“If we build it, they will come” mentality

I’m starting to think the shift from “shift left” (DevOps) to “shift down” (platform engineering) might be optimizing for standardization over flexibility — which is exactly what frustrated developers about DevOps in the first place.

The Questions I Can’t Stop Asking

Are we solving the right problem? Is low adoption a marketing/communication issue, or a signal that we’re building infrastructure developers don’t actually need?
Why does adoption fail despite measurable value? Our metrics show clear wins — faster deploys, fewer incidents. But if developers aren’t adopting, who are we winning for?
What does “80% adoption” really mean? The reports say successful platform teams hit 80% adoption. Is that 80% of developers using 20% of platform features? Or something else?
How does AI change the platform value proposition? If AI can generate infrastructure-as-code, does that make platforms more valuable (standardization) or less valuable (developers can self-serve via AI)?

What I Think We’re Getting Wrong

After 18 months of this work, here’s my hypothesis: We’re treating platform engineering as an infrastructure problem when it’s actually a product problem.

Infrastructure thinking says:

Build comprehensive, robust solutions
Measure uptime, performance, feature completeness
Standardize everything for consistency
Mandate adoption for compliance/security

Product thinking says:

Build what developers actually need, not what we think they should want
Measure developer satisfaction, time-to-value, voluntary adoption
Provide multiple paths for different use cases
Earn adoption through better UX

The platform teams winning in 2026 aren’t the ones with the most features — they’re the ones treating developers as customers, not users.

What Would Actually Help

If I’m honest about what would move the needle:

Measure developer outcomes, not platform health — track time from idea to production, not just deployment frequency
Treat adoption failure as product failure — if developers won’t use it, that’s our problem to solve, not theirs
Design for multiple paths, not one golden path — acknowledge that different teams have different needs
Kill the features nobody uses — just like product teams sunset underused features

Has anyone cracked this? What does high developer adoption actually look like at your organization — and more importantly, how did you get there without mandates?

I’m especially curious about the cultural and organizational changes that mattered more than the technical ones.

data_rachel · April 10, 2026, 5:19am

This resonates deeply. We’re going through similar growing pains at our financial services company — except we rebranded our DevOps team to “Platform Engineering” without changing much else, and guess what? Same problems, new name.

The Mandate Trap

Your point about the 36.6% using mandates hits home. We tried this. Here’s what actually happened:

What leadership expected:

Developers adopt platform → standardization → efficiency gains

What actually happened:

Developers game the system (deploy through platform, manage elsewhere)
Shadow platforms emerge for “real work”
Innovation dies because experimentation requires breaking the rules

We learned that mandate-based adoption is like forcing product-market fit — if you have to mandate it, you don’t have it.

Adoption Is a Product-Market Fit Problem

Your instinct about this being a product problem is spot on. We did Jobs-to-be-Done interviews with our developers and discovered:

Backend engineers want to deploy without thinking about infrastructure
ML engineers need custom GPU configurations and experiment tracking
Frontend engineers want CDN management and preview environments
Data engineers need batch job orchestration and data lake access

Our “one golden path” optimized for none of these. We were measuring platform uptime while developers rated us the lowest NPS of any internal service.

The AI Urgency

On your AI question — this is becoming urgent for us. Our platform team is asking: If developers can describe infrastructure needs to an AI and get working Terraform/Kubernetes configs, what’s our value proposition?

My take: The shift is from “we standardize infrastructure” to “we remove toil + enable capabilities.” AI doesn’t change that need — it just raises the bar for what “good” looks like.

What’s Actually Working

After 6 months of painful repositioning, here’s what moved adoption from 22% to 54%:

Start with empathy, not standardization — we shadowed developers for a week, watched where they struggled, built solutions for those problems
Measure developer outcomes, not platform outputs — time from PR to production, not number of features shipped
Treat adoption failure as product failure — when a team bypassed the platform, we asked “what did we miss?” not “why won’t they comply?”
Design for multiple paths — our backend teams use the golden path, ML teams have custom workflows, data teams have batch-optimized paths

The uncomfortable truth: High adoption required killing 60% of what we built and focusing on the 40% developers actually valued.

Does this mean platform engineering failed? No. But it means treating it like infrastructure instead of product development is what fails.

alex_infrastructure · April 10, 2026, 5:19am

Product person perspective here — and I think you’ve identified the core blindspot: platform teams are building infrastructure when they should be building products.

Let me translate this through a product lens.

The Product-Market Fit Test

If a product team launched a feature with 35% adoption, leadership would ask:

“Do we have product-market fit?”
“What job is this solving for users?”
“Why aren’t 65% of potential users converting?”

But when a platform team hits 35% adoption, the response is often:

“Developers don’t understand the value” (marketing problem)
“We need better documentation” (education problem)
“Let’s mandate it” (compliance problem)

That’s treating a PMF failure as a go-to-market problem.

If 65% of developers are voting with their feet, that’s not a communication issue — that’s a signal the product doesn’t solve their actual problems.

The Jobs-To-Be-Done Framework

@eng_director_luis’s JTBD approach is exactly right. When we apply this framework to platforms, the question shifts:

Wrong question: “How do we get developers to use our self-service infrastructure?”

Right question: “What job is a developer trying to accomplish when they need infrastructure?”

The answer usually isn’t “I want self-service infrastructure” — it’s:

“I need to test this change in production-like environment”
“I need to debug why my service is slow”
“I need to deploy this before end of sprint”

Your platform’s job is to make the infrastructure disappear, not to give them self-service access to infrastructure.

Product Thinking Questions

If you were building this as a product, you’d ask:

What’s our north star metric? Not “platform uptime” — probably “time from idea to production” or “% of deploys that are simple/fast”
Are we optimizing for standardization or ease? These often conflict. Does a developer care that their deploy uses the “approved Kubernetes pattern” or that it shipped in 5 minutes?
Capability count vs. pain solved — you have 50 capabilities. How many of those solve top-3 developer pains vs. “nice to have”?
What’s our ‘default path’ vs. ‘must use’ story? Golden path implies recommendation. Mandate implies lock-in. Which one drives better products?

Mandates vs. Pull

Here’s the uncomfortable truth: mandate vs. pull is the difference between monopoly and product-market fit.

Monopoly products (mandated platforms):

Don’t need to solve problems better than alternatives
Measure compliance, not satisfaction
Optimize for coverage, not delight

PMF products (pulled platforms):

Must be 10x better than alternatives (including doing it manually)
Measure voluntary adoption and NPS
Optimize for solving specific jobs extremely well

The AI Wild Card

On AI: I actually think AI will kill bad platforms and strengthen good ones.

Bad platforms (comprehensive but nobody uses them) → AI can replace with “generate what I need when I need it”

Good platforms (solve specific jobs better than alternatives) → AI makes them better (AI helps developers use the platform, AI helps platform team understand developer needs)

The question isn’t “will AI replace platforms” — it’s “will AI expose that we were building infrastructure nobody wanted in the first place?”

What Good Looks Like

High-adoption platforms I’ve seen share these traits:

North star metric: Time from idea to production (measured through voluntary adoption)

Leading indicators: Voluntary adoption rate, weekly active users, NPS
Lagging indicators: Deployment frequency, MTTR (these are table stakes, not the goal)

Product discipline:

Roadmap with explicit priorities and “not nows”
Developer interviews and feedback loops
Feature usage metrics and deprecation criteria
Onboarding UX that gets developers to first value in <15 min

Multi-path philosophy:

Golden path for common cases (optimized for speed)
Supported path for edge cases (documented, not mandated)
Escape hatches for true innovation (not penalized)

The uncomfortable truth: if you need mandates to hit 80% adoption, you’re optimizing for standardization and compliance, not for speed and simplicity — and developers can feel the difference.

alice_security · April 10, 2026, 5:19am

VP Eng here, and I want to add the organizational debt angle that nobody’s talking about: low platform adoption is often a symptom of organizational problems, not technical ones.

What “35% Adoption” Actually Means

When I see low adoption numbers, I don’t just see unused infrastructure — I see:

Organizational debt — complexity we’ve relocated instead of reduced
Trust debt — developers don’t believe the platform will solve their problems better than alternatives
Autonomy debt — developers feel they’ve lost control without gaining speed

These show up as “adoption challenges” but they’re really people and culture problems masquerading as technical problems.

The Hidden Cost of Centralization

You mentioned DevOps friction that platform engineering was supposed to solve. But here’s what I’ve observed: centralization doesn’t eliminate complexity — it just moves who bears the cost.

Before (DevOps model):

Every team solves infrastructure independently
High duplication, inconsistent quality
But: high autonomy, teams control their destiny

After (Platform model):

Platform team centralizes solutions
Lower duplication, higher consistency
But: lower autonomy, teams wait on platform roadmap

When adoption is low, ask: are we hearing “the platform doesn’t work” or “I’ve lost control”?

The Adoption Crisis Is a Trust Crisis

Low adoption often signals a trust problem in three dimensions:

Trust in decisions:

Do developers believe platform team understands their problems?
Do they trust the golden path won’t become a constraint later?
Do they believe “we’ll support you” when they hit edge cases?

Trust in time investment:

Migration to platform takes time — will it pay back?
Learning curve is real — is it worth it vs. what they know?
Lock-in risk — what if the platform team pivots/disbands?

Trust in autonomy:

Can they still innovate when they need to?
Will they get blocked by platform limitations?
Do they control their deployment destiny?

When these trust dimensions are broken, mandates make it worse because they force adoption without earning trust.

The Shadow Platform Problem

This is the canary in the coal mine for organizational health:

When I see shadow platforms (developers building workarounds), exit interviews tell the story:

“I couldn’t ship fast enough using the platform”
“The platform team didn’t understand our use case”
“I felt like I lost ownership of my infrastructure”

Shadow platforms aren’t rebellion — they’re developers trying to do their job when the official platform creates friction instead of reducing it.

The DevOps Backlash Is Repeating

Here’s the pattern I’m seeing repeat from DevOps to Platform Engineering:

Phase 1: Promised land

“Self-service everything! Developers are empowered!”

Phase 2: Reality sets in

Overwhelmed by complexity OR constrained by standardization
Neither state feels like empowerment

Phase 3: Pendulum swing

DevOps → too much complexity → Platform Engineering for standardization
Platform Engineering → too much constraint → ???

We keep swinging between “developers are overwhelmed” and “developers are constrained” instead of optimizing for developer agency — the ability to accomplish goals without being overwhelmed OR constrained.

What High Adoption Actually Requires

From organizations I’ve seen succeed with 70-80% voluntary adoption:

1. Agency Model, Not Golden Paths

Instead of “everyone uses the golden path,” offer tiered support:

Tier 1 (Fully managed): Platform owns everything, developer gets simplicity
Tier 2 (Configurable): Platform provides rails, developer configures
Tier 3 (Custom): Developer owns it, platform provides primitives

Different teams pick different tiers based on their needs, not mandates.

2. Measure Voluntary Adoption When Alternatives Exist

If you prohibit alternatives, 80% adoption is meaningless.

Real test: if developers could bypass the platform without penalty, would they still use it?

That number — voluntary adoption when alternatives exist — is your real PMF metric.

3. Optimize for Outcome Achievement, Not Self-Service Infrastructure

The job isn’t “give developers infrastructure self-service” — it’s “enable developers to ship features without infrastructure becoming the bottleneck.”

Sometimes that’s self-service. Sometimes it’s full-service. Sometimes it’s just removing a blocker.

4. Measure Agency, Not Just Productivity

High-productivity, low-agency teams burn out and lose top talent.

Track:

Can developers ship when they need to? (velocity)
Do they control critical decisions? (autonomy)
Do they understand the why behind constraints? (context)

The People Side Nobody Talks About

Platform engineering at 35% adoption has a talent retention problem nobody’s measuring:

Your top 10% engineers:

They’re the ones most frustrated by golden paths (they know when they need something custom)
They have the most mobility (can leave for places with more autonomy)
They’re often the ones building shadow platforms (because they can)

If platform engineering is losing your best engineers, adoption percentage is the wrong metric to optimize.

The AI Wild Card Changes Everything

On the AI question — I think AI enables agency at scale in a way platforms struggle with.

Imagine: Developer describes what they need → AI translates to platform capabilities → Platform provisions it

That world requires:

Platforms that expose primitives, not golden paths
AI that understands developer intent AND platform constraints
Flexibility by default, not as an exception

Platform teams that prepare for this will win. Those that double down on standardization and mandates won’t.

What I’d Do Differently

If I were in your shoes with 35% adoption:

Measure agency, not just adoption — survey: “Do you feel empowered or constrained by the platform?”
Design for segments, not averages — different teams need different solutions; one-size-fits-all is one-size-fits-none
Treat platform as enabler, not gatekeeper — success is when developers want to use it, not when they have to
Make flexibility the default, not exception — golden path should be fastest option, not only option

The hard truth: if you’re using mandates to drive adoption, you’re admitting the platform isn’t solving developers’ problems better than the alternatives.

And in 2026, with AI democratizing infrastructure, that’s an existential risk.