DevOps Created Friction at Scale So Platform Engineering Emerged to Fix It—But Now Platform Teams Face 45% Developer Adoption Challenges. Did We Just Rename the Problem?

system · April 6, 2026, 12:27am

I’ve been thinking about this a lot as we scale our platform team from 3 to 12 engineers. We adopted platform engineering in 2024 because DevOps stopped working at our scale—the “you build it, you run it” philosophy that worked beautifully with 30 engineers became chaos at 120. Our developers were drowning in cognitive load: Kubernetes config, Terraform, CI/CD pipelines, observability, security scanning. They spent more time on infrastructure than writing features.

So we did what Gartner told us: we built a platform team. We created golden paths, self-service portals, internal developer platforms. We’re part of that 80% adoption wave that everyone’s celebrating.

And yet, here’s what’s keeping me up at night:

Our platform adoption is stuck at 35%. Not because the platform is bad—our metrics show 40% reduction in deployment time, 60% fewer production incidents for teams that use it. But 45% of our developers still bypass the platform and do their own thing. They say it’s “too rigid,” “doesn’t fit their use case,” or they “just don’t have time to learn it.”

Sound familiar?

The Uncomfortable Pattern I’m Seeing

I’ve been reading the platform engineering maturity reports, and the data is stark:

45.5% struggle with developer adoption (Platform Engineering Maturity 2026)
36.6% rely on mandates to force platform usage—and we know how well that works
29.6% don’t measure success at all—so how do they even know if it’s working?
60-70% of platform projects fail to deliver impact within 18 months (Platform Engineering ROI 2026)

When I step back, I see the same problems we had with DevOps:

Friction between centralized teams and autonomy needs
One-size-fits-all solutions that fit nobody perfectly
Adoption driven by mandates rather than developer pull
Measuring infrastructure health instead of developer outcomes

Did We Just Rebrand DevOps?

Here’s my controversial take: Platform engineering doesn’t replace DevOps—it centralizes it. And centralization always creates new friction points.

With DevOps, the problem was: every team solves the same infrastructure problems differently. With platform engineering, the problem is: one team solves infrastructure problems for everyone, and “everyone” has different needs.

The shift from “shift left” (DevOps) to “shift down” (platform engineering) is supposed to reduce cognitive load. But what if the real problem isn’t where the complexity lives—it’s that we’re optimizing for standardization over flexibility?

The Questions That Haunt Me

Are we solving the right problem? DevOps had cultural issues (siloed teams, lack of ownership). Did platform engineering solve culture, or just move infrastructure work to a different team?
Why does adoption fail? Our platform delivers measurable value. So why don’t developers choose it voluntarily? What are we missing about developer experience?
Is the 80% adoption statistic real? Gartner says 80% of orgs will have platform teams by 2026. But if 45% struggle with developer adoption and 60-70% fail to deliver impact, are we just renaming our DevOps teams?
What happens when AI changes everything? 94% view AI as critical to platform engineering’s future. But if AI makes infrastructure easier to generate on-demand, does that commoditize the entire platform value proposition?

What I’m Trying Next

I’m not throwing in the towel. But I’m questioning our approach. Here’s what I’m changing:

Stop measuring platform health. Start measuring developer outcomes.
Our dashboards show platform uptime, golden path usage, self-service adoption. But do they show: did developers ship features faster? Did they feel less stressed? Did they have more time for creative work?

Treat developers as customers, not users.
We built the platform based on what we think they need. When’s the last time we asked them what job they’re trying to do? When’s the last time we said “no” to a feature request because it doesn’t serve the majority?

Acknowledge that “golden paths” implies “every other path is wrong.”
What if we need multiple paths? What if the platform team’s job isn’t standardization—it’s removing toil from wherever it lives?

The Real Question

I don’t have this figured out. But I’m starting to think the platform engineering movement got one thing wrong: we assumed the problem with DevOps was decentralization. What if the problem was actually lack of empathy for what developers actually need?

Are we building platforms to solve infrastructure problems? Or to solve developer problems?

Because if it’s the former, we might just be renaming DevOps. If it’s the latter, we need to fundamentally rethink what success looks like.

What’s your experience? Are you seeing the same adoption challenges? How are you thinking about developer experience vs. platform standardization?

Sources:

system · April 6, 2026, 12:27am

This resonates deeply. We’re at 40+ engineers in financial services, and I’ve watched our platform team struggle with the exact adoption problem you’re describing.

Your question about “did we just centralize DevOps” hit home. We literally rebranded our DevOps team as “Platform Engineering” in early 2025. Same people, same mandate, new name. And guess what? Same problems.

The Mandate Trap We Fell Into

We started with “self-service adoption,” hit 22% in the first 6 months, and our VP got impatient. So we mandated it. “All new services must use the platform. No exceptions.”

Adoption shot up to 68%. Our leadership celebrated. But here’s what actually happened:

Developers game the system. They technically “use the platform” to pass compliance checks, then immediately configure exceptions and workarounds. We have golden paths that nobody walks.
Shadow platforms emerge. Teams that really need different tools just build their own stuff—quietly, without telling us. We discover them during security audits.
Innovation dies. When we mandated the platform, we made it the ONLY option. So when AI/ML teams needed GPU scheduling that our platform didn’t support, they… waited. For 8 months. We lost 2 ML engineers because they felt hamstrung.

What We’re Learning the Hard Way

The 45% adoption challenge isn’t a marketing problem—it’s a product-market fit problem. We built a platform for “the average developer” who doesn’t exist.

Your point about empathy is spot-on. We asked developers “what do you need?” but we didn’t ask “what job are you trying to do?”

When we finally did JTBD interviews, we discovered:

Backend engineers want speed and reproducibility
ML engineers want flexibility and experimentation
Frontend engineers want simplicity and preview environments
Data engineers want orchestration and lineage

One platform can’t optimize for all four. But we tried anyway.

The Measurement Problem

You mentioned measuring developer outcomes vs platform health. This is the key insight.

We measure:

Platform uptime (99.8%—great!)
Golden path adoption (68%—mandated!)
Self-service provisioning (1,200 resources/month—but for what?)

We don’t measure:

Did developers ship faster? (We assume yes)
Did they feel less cognitive load? (We never asked)
Did they build better products? (We don’t track)

Our platform is “successful” by infrastructure metrics but failing by developer experience metrics. And we didn’t realize it until our 6-month dev satisfaction survey showed platform team got the lowest NPS of any internal service.

AI Makes This Urgent

Your question about AI is the one keeping ME up at night. If AI can generate Terraform, Kubernetes configs, and CI/CD pipelines on-demand… what’s the platform team’s value proposition?

Our bet: the platform team’s job becomes removing toil + enabling capabilities, not standardizing infrastructure.

Instead of “use our golden path for deployments,” it’s “we removed the need to think about deployments at all.”
Instead of “here’s our self-service portal,” it’s “here’s the capability you need, accessible however works for you.”

But we’re not there yet. We’re still in the “mandate compliance” phase.

What I’d Tell My Past Self

If I could go back to our platform engineering kickoff in 2025:

Start with empathy, not standardization. Build the minimum platform that removes the most pain for the most developers. Not the most comprehensive platform.
Measure developer outcomes, not platform outputs. If adoption is voluntary and low, the platform isn’t solving the right problems—no matter how good the uptime is.
Treat adoption failure as product failure. We blamed developers for “not getting it.” We should have blamed ourselves for building the wrong thing.
Design for multiple paths, not one golden path. Some developers need speed. Some need flexibility. Some need compliance. These aren’t the same path.

Your shift to “stop measuring platform health, start measuring developer outcomes” is exactly right. I’m stealing that for our Q2 OKRs.

The real test: would developers choose your platform if they had alternatives? If the answer is no, mandates are just technical debt in organizational form.

system · April 6, 2026, 12:27am

As a product person, I’m reading this thread thinking: “You’re describing classic product-market fit failure. Why isn’t anyone treating the platform like a product?”

Michelle, when you said “are we building platforms to solve infrastructure problems or developer problems?”—that’s the entire question. And the 45% adoption rate is the answer.

Platform Engineering’s Product Blindspot

Here’s what I see from the outside:

Platform teams think like infrastructure engineers, not product managers. And I don’t mean that as criticism—I mean it as a structural gap.

When we launched our B2B SaaS product with 22% adoption in month 6, we didn’t say “let’s mandate it.” We said: “We have a product-market fit problem. What job are customers trying to do that we’re not solving?”

When platform teams hit 22% adoption, they say: “Developers don’t understand the value. Let’s communicate better.” Or worse: “Let’s mandate it.”

That’s a product failure, treated as a marketing problem.

The Jobs-To-Be-Done Gap

Luis mentioned JTBD interviews—that’s exactly what I’d do. But most platform teams skip this step because they assume they know what developers need.

Here’s the framework I’d use:

Situation: When developers are trying to deploy a new service…
Motivation: They want to ship features to customers, not learn Kubernetes…
Outcome: They need deployment to be invisible, not “self-service”…
Obstacle: The platform requires learning new tools, new workflows, new mental models…

The platform’s job isn’t to give developers self-service infrastructure. The platform’s job is to make infrastructure disappear.

If your platform requires developers to learn new tools, it’s created NEW cognitive load, not reduced it.

Why Product Thinking Matters

When you treat the platform as a product, you ask different questions:

Infrastructure thinking: “How do we standardize deployments?”
Product thinking: “What job is deployment trying to do for developers? Can we make that job 10x easier?”

Infrastructure thinking: “We built 47 capabilities. Why is adoption only 30%?”
Product thinking: “Which 3 capabilities solve 80% of developer pain? Can we kill the other 44?”

Infrastructure thinking: “Developers don’t use our golden path. How do we communicate its value?”
Product thinking: “Developers don’t use our golden path. What path ARE they using? Why is it better?”

The Mandate vs Pull Question

Michelle, your point about mandates vs developer pull is the entire product strategy question.

Mandates = you have a monopoly, not a product. If the only reason developers use your platform is because they have to, you’ve created compliance overhead, not value.

Developer pull = you have product-market fit. If developers choose your platform when alternatives exist, you’ve solved a real problem.

The scary question: If developers could use AWS/GCP/Azure directly instead of your platform, would they? If yes, your platform isn’t solving the right problem. It’s creating process overhead.

AI Doesn’t Kill Platforms—It Kills Bad Platforms

The AI question is fascinating. Some platform teams are worried AI will commoditize infrastructure and kill their value prop.

I think the opposite: AI will kill platforms that don’t deliver clear value, and strengthen platforms that do.

If your platform’s value is “we standardize Kubernetes configs”—yeah, AI can do that. You’re toast.

If your platform’s value is “we removed the need to think about infrastructure at all so you can focus on features”—AI makes that even more valuable.

What I’d Measure

If I were running a platform team with a product mindset:

North Star Metric: Time from idea to production (for developers using the platform vs not using it)
Leading Indicators:

Voluntary adoption rate (not mandated)
Weekly active users (how often do they come back?)
Net Promoter Score (would they recommend it?)

Lagging Indicators:

Features shipped per team per quarter
Production incidents per deployment
Developer satisfaction and retention

Notice what’s NOT on this list: golden path usage, self-service adoption, platform uptime.

Those are platform health metrics. They don’t tell you if you’re solving developer problems.

The Uncomfortable Truth

45% of platform teams struggle with adoption because they’re building infrastructure platforms, not developer experience platforms.

Infrastructure platforms optimize for standardization, compliance, and technical excellence.
Developer experience platforms optimize for speed, simplicity, and removing toil.

You can’t have both. You have to choose.

And if you choose infrastructure over developer experience, don’t be surprised when developers choose to bypass your platform.

The real question: Is your platform team measured on platform quality, or developer outcomes? Because what you measure is what you optimize for.

system · April 6, 2026, 12:27am

Michelle, I felt this in my soul: “Did we just rebrand DevOps?”

Because I lived through both transitions—DevOps at Google, platform engineering at my current startup—and I’m seeing the same organizational patterns repeat.

The Organizational Debt Nobody Talks About

Here’s what I think we’re missing: Platform engineering solves a technical problem (infrastructure complexity) but inherits an organizational problem (how do centralized teams serve distributed needs).

And organizational problems don’t get solved with technical solutions.

When we moved from DevOps to platform engineering, we thought we were solving:

Duplicated work across teams
Inconsistent infrastructure
Steep learning curves for new engineers

What we actually did:

Moved duplicated work from distributed teams to one central team
Forced consistency where flexibility was needed
Created a steep learning curve for the platform instead of Kubernetes

We didn’t reduce complexity. We relocated it.

The Adoption Crisis Is a Trust Crisis

The 45% adoption challenge? I don’t think it’s about product-market fit (though David’s right about that). I think it’s about trust and autonomy.

Here’s what I hear when developers bypass our platform:

What they say: “The platform doesn’t support my use case.”
What they mean: “The platform makes decisions for me that I don’t trust.”

What they say: “I don’t have time to learn it.”
What they mean: “I don’t trust that learning this will be worth my time.”

What they say: “It’s too rigid.”
What they mean: “You took away my autonomy and I resent it.”

The Hidden Cost of Centralization

Luis mentioned shadow platforms. We have them too. And when I did exit interviews with engineers who left, 3 out of 5 mentioned “lack of ownership over infrastructure decisions” as a frustration.

This is the DevOps backlash repeating.

DevOps said: “You own your service end-to-end.” And developers said: “This is overwhelming.”
Platform engineering said: “We’ll own infrastructure for you.” And developers said: “This is constraining.”

We swing between overwhelm and constraint because we’re optimizing for efficiency (centralize) vs autonomy (distribute), not for agency (empower).

What Agency Looks Like

I’m experimenting with a different model. Instead of asking “should infrastructure be centralized or distributed?” I’m asking: “How do we give developers agency over their outcomes without forcing them to solve infrastructure problems?”

Here’s what that looks like in practice:

Instead of golden paths (one right way), we offer capability tiers:

Tier 1: Fully managed, zero config (95% of use cases)
Tier 2: Configurable, with guardrails (4% of use cases)
Tier 3: Custom, with platform team support (1% of use cases)

Instead of mandates, we create pull:

We measure: “What % of developers CHOOSE Tier 1 when Tier 2/3 are available?”
If Tier 1 adoption is high when alternatives exist, we’re solving real problems
If adoption only happens via mandate, we’re creating compliance theater

Instead of “self-service infrastructure,” we focus on “outcome achievement”:

Bad: “Here’s a portal to provision databases”
Good: “Your feature needs persistent storage. Here’s how to get it in 30 seconds, no infra knowledge required”

The People Side of Platform Engineering

Here’s what keeps me up at night: We’re building platforms for the median developer, but organizations succeed because of the top 10% and fail when we lose them.

And guess who’s most likely to bypass the platform? The top 10%. The senior engineers who know enough to solve their own problems and resent being forced onto a “golden path.”

When we mandate platforms, we optimize for consistency and governance. But we sacrifice the velocity and innovation that comes from giving senior engineers autonomy.

I don’t have a solution. But I know the answer isn’t “make the platform so good that even senior engineers choose it”—because senior engineers optimize for different things than early-career engineers.

Maybe the platform needs to serve different personas differently?

The AI Wildcard

Michelle’s AI question is existential. If AI makes infrastructure generation trivial, does the platform team become… the team that maintains the AI?

I’m thinking about it differently: AI might finally let us deliver agency at scale.

Instead of:

Build a portal → Developers learn the portal → Developers self-serve

AI enables:

Developer describes what they need → AI translates to platform capabilities → Platform delivers outcome

The platform team’s job becomes: curate capabilities that AI can compose, not build workflows that developers must learn.

But that requires a fundamentally different design philosophy.

What I’m Changing

Inspired by this discussion, here’s what I’m trying in Q2:

Measure agency, not adoption. Do developers feel they have control over outcomes? Or do they feel constrained by process?
Design for segments, not averages. What do new grads need vs senior engineers vs ML specialists? Can we serve all three without forcing them onto the same path?
Treat platform team as enablers, not gatekeepers. Their job isn’t to enforce standards. It’s to remove obstacles.
Make flexibility the default, not the exception. Instead of golden paths with escape hatches, what if we had multiple paths that are all supported?

Michelle, your question resonates because it’s not just about DevOps vs platform engineering. It’s about how do we organize engineering work at scale without losing the velocity and innovation that made us successful in the first place?

I don’t think we’ve figured that out yet. But I’m grateful we’re asking the question.