Six months ago, we launched our internal developer platform at the EdTech startup I lead. It’s technically excellent—deployment time dropped from 3 days to 2 hours, we eliminated 90% of infrastructure tickets, and early adopters love it. Yet adoption sits at 40%.
The other 60%? They’re still using their custom Terraform setups, their own deployment scripts, their preferred CI/CD configurations. And they’re not wrong to do so—their workflows work. But we can’t scale like this.
The Paradox I’m Seeing
Here’s what’s keeping me up at night: We’re bleeding talent while trying to solve an efficiency problem.
In Q1 2026, we lost 3 senior engineers. All three cited “loss of autonomy” in their exit interviews. Meanwhile, I’m reading that 45.3% of platform engineering teams cite developer adoption as their top challenge—not technical issues, but cultural resistance.
The feedback I’m hearing:
- “This is great, but I prefer my Terraform setup”
- “I don’t want to learn yet another system”
- “Why do we need to standardize when my approach works?”
And honestly? These aren’t bad arguments.
Are We Solving the Wrong Problem?
Research shows that only 16% of developer time is spent on new initiatives, while 79% report code maintenance as a major drain. Developers are drowning in maintenance work, burning out, leaving for companies where their work feels more impactful.
So we build platforms to “increase velocity.” But velocity toward what? More features that need maintenance? Faster deployments of the same technical debt?
Here’s my uncomfortable realization: Maybe developers resist standardization because we’re optimizing for organizational efficiency while they’re suffocating under cognitive load from legacy systems.
We’re solving for:
- Faster deployments
- Reduced infrastructure variance
- Lower operational overhead
- Compliance and security standardization
They need:
- Less time fighting build systems
- Fewer “works on my machine” problems
- Freedom to experiment with new approaches
- Meaningful work on features that matter
These aren’t always the same thing.
The Retention Connection
Attraction is working, but retention is breaking. We can hire great engineers, but we can’t keep them engaged. And I’m starting to suspect that platforms—when imposed rather than adopted—make this worse.
When developers feel that standardization strips away their autonomy over technical decisions, it removes one of the few areas where they still have control. No wonder they resist.
What I’m Learning (The Hard Way)
I came across Mallory Haigh’s “platform therapist” approach—the idea that successful platforms come from listening to actual workflows and daily struggles rather than building in a vacuum.
That hit hard. Our platform team spent 6 months building what we thought developers needed. We never asked what slowed them down most.
Here’s what voluntary adoption looks like: When lead time drops from days to minutes, developers adopt because they want their features shipped faster. Not because they were told to.
The Question I’m Wrestling With
How do we balance:
- Standardization (which organizations need to scale efficiently and maintain compliance)
- Autonomy (which developers need to stay engaged and do their best work)
Because right now, it feels like we’re forcing a choice: standardize and lose talent, or preserve autonomy and fail to scale.
I don’t think that’s actually the trade-off. But I haven’t figured out the answer yet.
For those of you who’ve navigated this—how did you get developers to adopt platforms without it feeling like a loss of control? And for those resisting standardization on your teams, what would make you enthusiastic adopters instead?