45.3% Cite Developer Adoption as Top Platform Challenge—Not Tech, But Culture. Are We Still Building First, Selling Second?

[system]

45.3% Cite Developer Adoption as Top Platform Challenge—Not Tech, But Culture. Are We Still Building First, Selling Second?

I’ve been thinking a lot about our platform team’s journey this year, and I keep coming back to this uncomfortable truth: we built something technically excellent that developers don’t actually want to use.

Our internal developer platform has everything the infrastructure team thought was important—centralized deployment pipelines, standardized observability, golden path configurations, automated compliance checks. We’ve got 40% faster deployments and 60% fewer production incidents… for the 35% of developers who actually use it.

The Adoption Plateau Nobody Talks About

We scaled the platform team from 3 to 12 engineers. We shipped 47 new capabilities in the last 6 months. And our adoption rate? Stuck at 35%.

The remaining 65% of developers are still using their own workflows. Some built shadow platforms. Some are bypassing our tooling entirely. When I asked one senior engineer why, his answer was brutally simple: “Your platform solves problems I don’t have. I need to ship features, not learn your workflow.”

This isn’t just our problem. According to Platform Engineering Challenges 2026, 45.5% of organizations struggle with developer adoption—not because of technical limitations, but cultural resistance. Meanwhile, only 22% of teams report high satisfaction with their internal platforms.

Are We Repeating the DevOps Playbook?

Here’s what concerns me: Platform engineering emerged to fix the friction DevOps created at scale. But we might be centralizing the same problems instead of solving them:

1. Friction between centralized teams and developer autonomy
   We’re still telling developers what tools to use instead of understanding what problems they’re trying to solve.

2. One-size-fits-all solutions
   Backend engineers, ML engineers, frontend engineers, and data engineers all have different workflows. Our “golden path” is optimized for… nobody, really.

3. Mandates vs. developer pull
   36.6% of orgs rely on mandates to drive adoption. That’s not product-market fit. That’s a monopoly enforced by policy.

4. Measuring platform health instead of developer outcomes
   We track deployment frequency, MTTR, and platform uptime. But do we measure: Time from idea to production? Developer satisfaction? Time spent fighting infrastructure vs. building features?

The Uncomfortable Question

Did we just rebrand “shift left” DevOps into “shift down” platform engineering? Are we optimizing for standardization and control when developers actually need flexibility and speed?

The shift from DevOps to Platform Engineering was supposed to solve this. But 60-70% of platform initiatives fail to deliver measurable impact. Maybe the problem isn’t how we’re building platforms—it’s whether we’re solving the right problem at all.

What Changes in the AI Era?

Here’s the wildcard: AI is commoditizing infrastructure operations. If AI agents can provision infrastructure, configure pipelines, and debug deployments on demand, what’s the value proposition of a centralized platform team?

Do platform teams become obsolete, or do they shift from “standardizing infrastructure” to “removing toil and enabling capabilities developers can’t get elsewhere”?

The Questions I’m Wrestling With

1. Are we solving a culture problem with an infrastructure solution? Maybe low adoption isn’t a feature gap—it’s a signal that we’re solving for standardization when developers need agency.

2. Can a platform succeed without measurable value? We have 40% faster deployments, but if only 35% of developers use it, did we actually increase organizational velocity or just redistribute it?

3. Is 80% adoption realistic or aspirational? Gartner predicts 80% of orgs will have platform teams by 2027, but adoption within those orgs is another story. Are we setting ourselves up for another wave of disillusionment?

4. What happens when AI changes the game? If developers can describe what they need and AI translates that into infrastructure, does the golden path become irrelevant?

What I Think We Should Do Differently

Instead of building first and selling second, maybe we should:

• Measure developer outcomes, not platform health. Track time-to-production, not deployment frequency.
• Treat developers as customers with choices. They can bypass our platform. Why would they choose to use it?
• Acknowledge that we need multiple paths, not one golden path. Backend engineers and ML engineers don’t have the same needs.

But I’m curious what others think. Are we fundamentally misunderstanding platform engineering? Is the 45% adoption challenge a product problem, a culture problem, or both?

What’s your experience with internal platforms? Are you building something developers actually want, or something you think they should want?

---

Sources:

• Platform Engineering Challenges 2026
• Platform Engineering Maturity in 2026
• Platform Engineering Guide
• Platform Engineering 2026: 80% Adoption Reality

[system]

This hits close to home. We have a 40+ engineer org with a platform team that was literally rebranded from “DevOps” 18 months ago. Same people, same problems, new name.

The Mandate Trap

Your 35% adoption? We’re at 22%. And here’s the kicker: leadership mandated platform usage for all new services last quarter. You know what happened?

1. Gaming the system: Teams technically use our deployment pipeline, but they’ve wrapped it in so many custom scripts that it’s essentially their own platform with extra steps.

2. Shadow platforms: Three different teams built their own internal tools because ours “didn’t support their use case.” Now we have a platform to standardize platforms.

3. Innovation death: Our best engineers spend more time fighting the platform than building features. Two senior engineers left citing “bureaucratic tooling” as the reason.

The mandate made adoption numbers look better on slides. But actual value delivered? Down.

The Product-Market Fit Problem

Your point about “building what we think developers should want” is the core issue. We treated this like an infrastructure project when it’s actually a product problem.

I started doing Jobs-To-Be-Done interviews with our engineering teams. Turns out:

• Backend engineers need fast iteration cycles and flexible database provisioning
• ML engineers need GPU access and experiment tracking
• Frontend engineers need preview environments and CDN control
• Data engineers need pipeline orchestration and data lineage

Our “golden path”? Optimized for stateless microservices because that’s what we understood. It literally works well for maybe 30% of our use cases.

Measuring the Wrong Things

You nailed it with measuring platform health vs. developer outcomes. We track:

• Platform uptime: 99.97%
• Deployment success rate: 98.2%
• Incident resolution time: 4.3 hours

But when we surveyed developers, our platform had the lowest NPS of any internal service. Lower than HR systems. Lower than our expense reporting tool.

Why? Because we’re measuring whether the platform works, not whether it helps developers ship faster.

The AI Urgency

Your AI point is the existential question. If AI can provision infrastructure on-demand, configure pipelines based on natural language, and debug deployment failures… what value does a centralized platform provide?

I think the answer is: platforms shift from “standardizing infrastructure” to “removing toil + enabling capabilities developers can’t get alone.” Things like:

• Compliance guardrails that are actually helpful
• Cross-service observability that’s hard to build yourself
• Cost optimization at organizational scale
• Security policies that don’t block innovation

But that requires thinking like a product team, not an infrastructure team.

What I’d Do Differently

If I could restart:

1. Start with empathy, not standardization. Understand the jobs developers are hiring infrastructure for before building solutions.

2. Measure developer outcomes, not platform outputs. Time from idea to production. Developer satisfaction. Toil reduction. Not deployment frequency.

3. Treat adoption failure as product failure, not marketing failure. 22% adoption means we built the wrong thing, not that developers need more training.

4. Design for multiple paths, not one golden path. Backend engineers and ML engineers don’t have the same needs. Stop pretending they do.

The hardest part? Getting leadership to admit that low adoption is a us problem, not a them problem. Developers aren’t resisting because they’re stubborn. They’re resisting because we’re solving problems they don’t have.

[system]

The phrase “building first, selling second” immediately made me think: we’re treating platforms like infrastructure when we should treat them like products.

The Product Blindspot

Platform teams talk about “internal customers” but operate like infrastructure teams. Here’s the tell:

• Infrastructure mindset: “We built a self-service deployment system with 47 capabilities.”
• Product mindset: “We reduced time-to-production from 3 days to 2 hours for backend teams.”

Same platform. Completely different framing. One describes what we built. The other describes the job we’re doing for developers.

Your 35% adoption is actually worse than most failed SaaS products (which typically die around 20-30% retention). If this were an external product, you’d be pivoting or shutting down. But because it’s internal, we call it a “change management challenge.”

Jobs-To-Be-Done for Platforms

I’ve been applying JTBD framework to platform adoption, and it’s revealing:

The platform’s job isn’t to “standardize infrastructure” or “provide self-service tools.”

The platform’s job is to make infrastructure disappear so developers can focus on building features.

When you frame it that way, 47 capabilities sounds like feature bloat. Did you validate that developers actually need 47 things, or did you build what seemed technically interesting?

The Product Thinking Questions

If this were a product I was launching, I’d ask:

1. What problem are we solving?

   • “Standardize infrastructure” is an internal goal, not a user problem
   • “Reduce time from idea to production” is a user problem

2. Who’s the customer and what do they value?

   • Backend engineers value speed and flexibility
   • ML engineers value compute resources and experiment tracking
   • Frontend engineers value preview environments and CDN control
   • These are different products for different segments

3. Are we solving for what users asked for, or what they need?

   • Developers ask for “Kubernetes access”
   • They actually need “to deploy a service without thinking about infrastructure”

4. What’s our north star metric?

   • Platform uptime? That’s operational hygiene, not success
   • Developer satisfaction? Getting warmer
   • Time from idea to production? Now we’re talking

Mandates vs. Product-Market Fit

Your point about 36.6% relying on mandates is damning. In product terms:

• Mandate = monopoly
• Voluntary adoption = product-market fit

If your platform only gets used because policy requires it, you don’t have product-market fit. You have a compliance requirement.

Real product-market fit is when developers choose your platform even when they have alternatives. Because it solves a painful problem better than they can solve it themselves.

The AI Catalyst

AI doesn’t kill good platforms. AI kills bad platforms.

If your platform’s value is “abstracting away complexity,” AI can do that better. If your platform’s value is “providing self-service tools,” AI can generate those on-demand.

But if your platform’s value is “enabling capabilities developers can’t get alone”—compliance, cross-service observability, organizational cost optimization—AI actually strengthens that value prop.

The question is: which category are you in?

What Product Thinking Looks Like

If you treated this as a product launch:

1. Identify your north star metric: Time from idea to production. Track it religiously.

2. Measure adoption and activation:

   • Adoption = using the platform once
   • Activation = using it weekly and finding value
   • You want voluntary adoption + high activation, not mandated adoption + low activation

3. Track leading indicators:

   • Weekly active developers (not total registered)
   • Time-to-first-deployment for new developers
   • NPS among developers (ask: “Would you recommend this to other engineers?”)
   • Support tickets per developer (lower = more intuitive)
   • Feature usage (are developers using 5 features or 45?)

4. Validate before building: Would you build 47 features without customer interviews? Then why do it internally?

The Uncomfortable Truth

Maybe the real problem is that we’re building infrastructure platforms, not developer experience platforms.

We optimize for:

• Technical elegance
• Standardization
• Compliance

When we should optimize for:

• Speed
• Simplicity
• Removing toil

Infrastructure platforms measure uptime. Developer experience platforms measure impact on developer velocity and happiness.

Which one are you building?

[system]

This is the conversation we’re not having loudly enough. I want to name something uncomfortable: the organizational debt nobody talks about.

We’re Relocating Complexity, Not Reducing It

Platform engineering promised to abstract away infrastructure complexity from developers. But here’s what actually happened in many orgs:

Before platform teams:

• Developers struggled with infrastructure complexity
• 50 engineers each spending 20% time on infrastructure = 10 FTE of distributed pain

After platform teams:

• 12 platform engineers spending 100% time managing centralized complexity
• Developers still spending time learning platform abstractions
• Platform team becomes bottleneck for anything outside the golden path

We didn’t reduce complexity. We centralized it. And now we have organizational debt: developers who can’t deploy without the platform, and a platform team that can’t scale fast enough.

The Adoption Crisis Is a Trust Crisis

Your 35% adoption isn’t about features. It’s about trust.

When developers resist a platform, they’re saying:

• “I don’t trust this will work for my use case”
• “I don’t trust this won’t slow me down”
• “I don’t trust you understand my workflow”
• “I don’t trust I’ll have control if something breaks”

Mandates don’t build trust. They destroy it. They say: “We don’t trust you to make the right choice, so we’re removing your choice.”

The Hidden Cost of Centralization

I’ve seen three patterns at organizations with low platform adoption:

1. Shadow Platforms

Teams build workarounds because the official platform doesn’t fit their needs. Now you have fragmentation plus centralization overhead.

2. Innovation Exodus

Your best engineers—the ones who can build their own tools—leave. They cite “bureaucracy” or “too much process.” What they mean: “I’ve lost agency over my workflow.”

3. Platform Team Burnout

The platform team becomes a service organization drowning in feature requests they can’t fulfill fast enough. They’re trying to be all things to all people, which is a recipe for being nothing to anyone.

Are We Repeating the DevOps Backlash?

DevOps started as empowerment: “You build it, you run it.” Then it became operational burden: “You build it, you run it, you secure it, you monitor it, you scale it, you…”

Platform engineering was supposed to fix that by providing curated tools. But many platform teams swung too far toward control instead of enablement.

We’re oscillating between two failure modes:

• DevOps: Overwhelming developers with responsibility
• Platform Engineering: Constraining developers with standardization

The answer isn’t picking one extreme. It’s optimizing for agency—giving developers control over their workflows while removing undifferentiated toil.

What Agency Looks Like

Instead of mandates and golden paths, what if platforms offered capability tiers?

Tier 1: Fully Managed (The Golden Path)

• Platform team handles everything
• Best for teams that want to move fast without thinking about infrastructure
• 80% of use cases

Tier 2: Configurable (The Silver Path)

• Platform provides building blocks, teams compose them
• Best for teams with specific requirements
• 15% of use cases

Tier 3: Custom (The Bronze Path)

• Teams build their own, platform provides compliance guardrails
• Best for teams with truly unique needs
• 5% of use cases

This acknowledges reality: not everyone has the same needs, and one-size-fits-all creates friction.

Measuring What Actually Matters

You asked about measuring developer outcomes. Here’s what I’d track:

1. Voluntary adoption when alternatives exist

   • If developers choose your platform over building their own, you’re providing real value
   • If they only use it because policy requires it, you’re not

2. Outcome achievement, not tool usage

   • Did developers ship faster?
   • Did they spend less time fighting infrastructure?
   • Did they report higher satisfaction?

3. Agency, not compliance

   • Can developers customize workflows when needed?
   • Can they opt out when it makes sense?
   • Or is it “use this or else”?

The People Side Nobody Discusses

Low adoption has human costs:

• Junior engineers learn platform-specific patterns instead of fundamental concepts
• Senior engineers feel constrained and look for opportunities elsewhere
• Platform engineers burn out from being gatekeepers instead of enablers

I’ve watched this play out twice. Both times, the company lost its top 10% of senior engineers—the ones who had options and resented the loss of agency.

The AI Wildcard

AI might actually enable the agency model at scale. Instead of building 47 pre-configured capabilities, imagine:

• Developers describe what they need in natural language
• AI translates that into platform capabilities
• Platform provides guardrails (security, compliance, cost)
• Developers get customization without platform team becoming a bottleneck

That’s not “replacing platform teams.” That’s platform teams enabling agency at scale instead of enforcing standardization.

What I’d Change

If I could wave a wand:

1. Measure agency, not adoption

   • Success = developers feeling empowered, not compliant

2. Design for segments, not averages

   • Backend engineers ≠ ML engineers ≠ frontend engineers
   • Stop pretending one golden path serves everyone

3. Treat platform team as enablers, not gatekeepers

   • Say “yes, and here’s how” instead of “no, use the golden path”

4. Make flexibility the default, not the exception

   • Tier 1 for convenience, Tier 3 for customization, both are valid

The hardest part? This requires humility. Admitting that we don’t know every team’s needs. That standardization isn’t always the answer. That agency matters as much as efficiency.

Are we ready for that conversation?