We Built an Internal Developer Platform. Adoption Hit 80%. Developer Happiness Hit a New Low. The Unintended Consequences of Paving the Road

General
1

We Built an Internal Developer Platform. Adoption Hit 80%. Developer Happiness Hit a New Low. The Unintended Consequences of ‘Paving the Road.’

I need to confess something uncomfortable: Our platform engineering initiative succeeded on every metric except the one that matters—developer satisfaction.

The Setup: Following Best Practices

18 months ago, we created a dedicated platform team. The mandate: Build an Internal Developer Platform (IDP) to reduce cognitive load and improve DevEx.

We did everything the 2026 playbooks recommend:

  • Golden paths for common workflows
  • Self-service infrastructure provisioning
  • Standardized CI/CD templates
  • Integrated observability and security

The metrics looked incredible:

  • 80% platform adoption across engineering
  • Deployment time reduced 60%
  • Infrastructure consistency at 95%
  • Security compliance automated

We presented at conferences. We got featured in case studies.

Then the Developer Survey Came Back

Developer satisfaction: 2.1 out of 5.

The feedback was brutal:

“The platform is fast but inflexible. I can’t customize my workflow anymore.”

“I have to file a ticket and wait 2 weeks for platform team approval to try a new library.”

“The golden path is great for simple cases. For anything complex, I’m fighting the platform instead of solving problems.”

“It feels like the platform team optimizes for their convenience, not ours.”

What Went Wrong: Paved Road Became Walled Garden

The insight hit me hard: We had optimized for consistency over developer autonomy.

Our “golden path” worked beautifully—as long as your use case matched our assumptions. The moment you needed something different, the platform became an obstacle.

Cognitive load didn’t decrease—it shifted:

  • Before: Choice paralysis about which tools to use
  • After: Frustration fighting platform limitations

According to 2026 platform engineering research, this is a common failure mode. IDPs that mandate “one way” create resentment. The best platforms provide the easiest path without blocking alternative paths.

The Deeper Issue: Gate Keeper vs Service Provider

We positioned the platform team as gatekeepers instead of service providers.

Developers needed platform team approval for:

  • New languages/frameworks
  • Custom build configurations
  • Database schema changes
  • Infrastructure modifications

This created bottlenecks, dependency, and frustration.

One senior engineer told me: “I left AWS for more autonomy. Now I have less autonomy than I did at AWS. At least AWS let me customize things.”

The Question We Should Have Asked

Instead of “How do we get 100% platform adoption?” we should have asked:

“How do we make the platform so valuable that developers choose it organically?”

Mandatory adoption kills the feedback signal. If developers have no choice, how do you know if the platform actually solves their problems?

What We’re Changing

We’re treating this as a product failure and applying product thinking:

  1. Platform adoption is now optional (for next 6 months)
  2. Escape hatches formalized (80% use golden path, 15% approved alternatives, 5% custom with justification)
  3. Platform team measured on NPS, not adoption rate
  4. Weekly “platform office hours” for feedback and feature requests
  5. Quarterly platform roadmap reviews with developer input

Early results (2 months in):

  • Adoption dropped slightly to 75% (the 5% who left were our loudest critics—useful signal!)
  • Platform NPS improved from -20 to +15
  • Feature requests up 300% (people engaging now that they feel heard)
  • Psychological safety scores improving

The Balance I’m Still Seeking

There’s a real tension here:

Standardization enables scale, security, consistency.
Flexibility enables innovation, customization, developer happiness.

How do you standardize without stifling? How do you provide golden paths without creating walled gardens?

My Questions for This Community

  1. Has anyone found the sweet spot between golden paths and flexibility?

  2. How do you handle teams that refuse platform adoption? Force them? Let them opt out? Something in between?

  3. What governance model works? How do you balance platform team’s need for consistency with feature team’s need for autonomy?

I’d love to hear from folks who’ve navigated this successfully—especially at scale (100+ engineers).

Platform engineering is infrastructure for product velocity—but only if developers actually want to use it. Forced adoption kills the signal that tells you whether you’re building the right thing.

2

Maya, this validates every concern I’ve had about platform mandates. You’re describing the classic mistake: treating platform as infrastructure instead of product.

The Gatekeeper vs Service Provider Distinction

This is crucial. The moment platform team becomes a bottleneck for decisions, you’ve created organizational dysfunction.

Our governance model:

80/15/5 Rule:

  • 80% use golden paths (optimized, supported, easy)
  • 15% use approved alternatives (documented, team owns support)
  • 5% get custom exceptions (with architecture review + justification)

This acknowledges reality: No single path serves 100% of use cases.

Platform as a Product, Not a Mandate

Your shift to “optional adoption” is brilliant. Here’s why:

When adoption is mandatory, platform team optimizes for compliance, not value. They measure “did teams use it?” not “did it make their lives better?”

When adoption is optional, platform team must compete for users. They measure NPS, iterate based on feedback, and actually solve real problems.

Platform NPS should be the north star metric, not adoption rate.

The Escape Hatch Question

@maya_builds asked about teams that refuse adoption. My take:

Let them opt out—but make them own the consequences.

If Feature Team X wants to use custom infrastructure:

  • They own security compliance for their custom stack
  • They own on-call for their custom services
  • They document their approach for knowledge sharing

Usually, teams realize golden path is easier. But the option to go custom preserves autonomy and surfaces real platform gaps.

When multiple teams request the same exception, that’s a signal: The platform should support that use case.

Question for You

You mentioned platform NPS went from -20 to +15 after making adoption optional. What specific changes resonated most with developers?

Was it just the optionality, or did you change platform features based on feedback?

3

Michelle’s 80/15/5 rule is exactly right. Let me share how we implemented this thinking.

Platform IS a Product

We made platform adoption optional for the first 6 months after launch. Controversial decision—executives wanted “mandate it for consistency.”

But I argued: If we mandate adoption, we lose the signal that tells us whether we built the right thing.

Forced the platform team to “sell” the value. Iterate based on real feedback. Treat developers as customers, not compliance targets.

Result: Organic adoption reached 75% after 6 months. Higher satisfaction than when we mandated 80% adoption.

The 25% who didn’t adopt? Their feedback was GOLD. Revealed platform limitations we’d missed.

The Cultural Shift This Requires

Platform team had to change mindset from:

  • “We built it, use it” → “How can we make this so good you want to use it?”
  • “Here’s what you get” → “What do you need?”
  • “File a ticket” → “Let’s pair on this”

This requires product thinking + customer empathy, not just engineering excellence.

Continuous Discovery with Developer Users

We run “platform office hours” weekly. Not for support tickets—for feedback and co-design.

Developers bring problems. Platform team explores solutions together. Sometimes the answer is “we’ll build that.” Often it’s “here’s a workaround” or “let’s document this exception.”

This ongoing dialogue prevents platform from drifting away from real needs.

The Constraint vs Enablement Question

Your point about “enabling constraints vs limiting constraints” resonates with my leadership philosophy.

Good platforms remove low-value decisions so engineers can focus on high-value problems.

Example: “Which cloud provider?” → Golden path says AWS, saves weeks of evaluation
Example: “How do we handle auth?” → Shared library, don’t rebuild from scratch

Bad platforms remove agency entirely.

Example: “Can I use Rust for this service?” → Platform says no, even though Rust is best tool for job
Example: “Can I customize the CI pipeline?” → Platform says file a ticket, wait 2 weeks

The difference: Does the constraint enable developers to do better work, or just make platform team’s job easier?

My Recommendation

Platforms should optimize for developer outcomes, not platform team convenience.

Measure: Does this platform help developers ship faster, with less friction, with more confidence?

If not, it’s infrastructure theater.

4

Your experience with the platform team as bottleneck mirrors what we dealt with in fintech.

The Federated Platform Model

Our compromise: Federated platform team structure.

Instead of central platform team as sole owners, we have:

  • Central platform team (sets standards, builds core tools)
  • Platform ambassadors embedded in each feature team (20% time)

Ambassadors:

  • Represent feature team needs to platform team
  • Evangelize platform capabilities to their teams
  • Contribute to platform development from feature team perspective

This creates bidirectional feedback loop:

  • Platform team hears real needs continuously
  • Feature teams have agency in platform direction
  • “Us vs them” dynamic reduced

The Caveat: Requires Psychological Safety

This only works if engineers feel safe saying “the platform doesn’t work for us.”

If platform team treats feedback as criticism (defensiveness) or feature teams fear retaliation for not adopting, the model breaks.

We had to coach platform team on receiving feedback without defensiveness. Hard skill, critical for success.

Preventing Platform Team Bottleneck

To prevent platform team from blocking feature teams:

  1. Default to yes on exception requests (reverse the burden of proof)
  2. SLAs on platform requests (respond in 24hrs, even if answer is “we’re investigating”)
  3. Rotation of feature engineers into platform team (empathy building, knowledge transfer)

This keeps platform responsive instead of bureaucratic.

The Question of Standardization

Michelle asked about balancing standardization with flexibility. My framework:

Standardize infrastructure. Don’t standardize workflows.

Standardize:

  • Security baselines
  • Observability integration
  • Infrastructure provisioning

Don’t standardize:

  • Language/framework choices (within security bounds)
  • Build pipelines (provide templates, allow customization)
  • Development workflows (team autonomy)

This maintains compliance while preserving autonomy where it matters.

5

From a product strategy lens, this is a classic platform trap. Let me share the business thinking.

Platform Engineering Is Infrastructure for Velocity

Strategic view: Platform engineering is supposed to be a competitive advantage. Spotify’s Backstage, Netflix’s platform—these became moats.

But those platforms succeeded because they solved real developer pain, not because executives mandated adoption.

The Platform Product Canvas

When evaluating platform investments, I use this litmus test:

“Would developers use this if they had a choice?”

If the answer is no or “maybe,” the platform is failing.

Indicators of platform failure:

  • Adoption requires mandate
  • Developers route around the platform when possible
  • Complaints about “bureaucracy” and “tickets”
  • Platform team defensive about feedback

Indicators of platform success:

  • Organic adoption without mandate
  • Developers request new platform features
  • Platform team actively iterates based on feedback
  • Platform cited in developer satisfaction surveys as positive

Measuring Platform “Pull” vs “Push”

I track:

  • Pull: Feature requests from developers, voluntary adoption, positive NPS
  • Push: Mandated adoption, compliance enforcement, tickets for exceptions

High pull = platform solving real problems.
High push = platform creating friction.

The Warning: Technical Debt Disguised as Progress

Platform that doesn’t improve DevEx is technical debt disguised as infrastructure investment.

You spend money building it. You spend political capital mandating it. Developers resent it. Velocity doesn’t improve. Now you’re stuck—too expensive to abandon, too problematic to keep.

Better to:

  1. Start with optional platform
  2. Iterate based on feedback
  3. Let developers vote with their feet
  4. Scale what works, kill what doesn’t

Offer

I’ve built a Platform Product Canvas template that applies product thinking to internal platforms:

  • Value proposition (what problem does this solve?)
  • Customer segments (which teams need this?)
  • Success metrics (how do we know it’s working?)
  • Feedback loops (how do we iterate?)

Happy to share if useful. DM me.

Question back: @maya_builds, what percentage of your platform roadmap comes from developer requests vs platform team initiatives? Curious about the balance.