Three weeks ago, I sat in a retrospective where a senior developer finally snapped.
“Your platform is like a prison. Every simple task requires five approvals, three tickets, and a blood sacrifice to the YAML gods.”
The platform team was stunned.
They’d spent two years building “developer-friendly” abstractions.
Plot twist: Not one developer had been involved in the design.
THE PLATFORM PERCEPTION GAP™
After interviewing 500+ developers about their platform experiences, I discovered something shocking:
What Platform Teams Think Developers Want:
- Sophisticated abstractions
- Zero infrastructure knowledge required
- Complete automation of everything
- “GitOps all the things”
What Developers Actually Want:
- Deploy my code in under 10 minutes
- Debug problems without a PhD in Kubernetes
- Change things without breaking production
- Know what’s actually happening
The gap between these lists? That’s where platforms go to die.
THE LOUDEST VOICE SYNDROME
Here's what really happens in platform design meetings:
The loudest, most technical person dominates. They promise the moon. "We'll build a platform so intelligent, developers won't even need to think!"
Everyone else stays quiet. Not because they agree, but because challenging the "expert" feels like career suicide.
I watched this destroy a platform at a fintech. Their principal engineer convinced leadership they needed a "Netflix-level platform" for their... 12 microservices. Anyone who questioned it was labeled "not technical enough."
18 months later: £3M spent, 0% adoption. The quiet junior who suggested "maybe we just need better CI/CD" was right all along.
Pro tip: In your next platform meeting, ask the quietest person what they think. Their answer will surprise you.
THE 3 WORDS THAT PREDICT PLATFORM FAILURE
Want to know if your platform is doomed? Listen for these three words:
“Just use the…”
As in: - “Just use the platform CLI” - “Just use the abstraction layer” - “Just use the documentation”
Every “just” is a developer grinding their teeth.
I tracked this across 20 platform teams. Those averaging 5+ “justs” per conversation had:
- 73% lower adoption rates
- 4x more shadow IT
- Developers actively working around the platform
Want to see me diagnose these problems live? In next week’s masterclass, I’ll show you exactly how to spot and fix the “just” problem.
THIS WEEK’S PLATFORM PSYCHOLOGY INSIGHT
From your emails this week, the #1 frustration was:
“We built it exactly to spec, but nobody uses it.”
Here’s the painful truth: You’re solving the wrong problem.
Platform teams build for the developers they imagine, not the developers they have.
Real example: A platform team spent 6 months building a “simplified” deployment system.
Requirements:
- Fill out a 47-field form
- Wait for 3 approvals
- Automatic resource limits (non-negotiable)No direct kubectl access
Developer solution? They deployed directly to AWS.
Platform adoption: 12%.
THE 10-MINUTE PLATFORM EMPATHY TEST
Next week, sit with a developer and watch them deploy a simple change. No helping. No explaining. Just observe. Count:
1. How many screens they visit
2. How many times they check documentation
3. How many error messages they see
4. How many times they curse (silently counts)
5. How long until they give up or succeed
One platform lead tried this and messaged me:
“I wanted to crawl under my desk. It took 47 minutes and 12 browser tabs.”
METRICS THAT LIE (AND WHY WE LOVE THEM)
Platform teams love metrics that make them look good:
- "99.9% platform uptime!" (excluding planned maintenance, deployments, and "expected" failures)
- "100% GitOps adoption!" (because we removed all other options)
- "50% faster deployments!" (compared to our previously broken system)
Real metrics developers care about:
- Time from code commit to production
- How long to debug a failed deployment
- Number of people needed to approve a change
One team celebrated their "100% automated deployments." Reality? Developers had built a shadow Jenkins server because the "automated" platform required 47 manual configuration steps.
REAL STORY: THE REBELLION THAT SAVED A PLATFORM
A retail client’s platform had 8% adoption after 18 months.
Developers had built their own “Underground Railroad” - a hidden Jenkins server that just… worked.
Instead of shutting it down, we studied it:
- 3 steps to deploy (vs 11 on the platform)
- Plain Docker files (vs custom DSL)
- Direct feedback (vs abstracted logs)
- 5-minute deploys (vs 35-minute average)
We rebuilt the platform based on the “rebel” solution.
Adoption hit 80% in 60 days.
The lesson? Your developers already built your best platform. You just need to look.
HOW TO GET BRUTAL HONESTY FROM YOUR TEAM
Developers won’t tell you the truth in meetings. Here’s how to get real feedback:
- The Anonymous Slack Channel
Create #platform-confessions. No names. No judgment. Watch the truth pour in.
- The “What Sucks?” Session
Monthly meeting with one rule: Only discuss what’s broken. No solutions. No defensiveness. Just pain points.
- The Shadow IT Audit
Find out what developers built themselves. That’s your roadmap.
- The New Developer Test
Have your newest hire document their first deployment. Fresh eyes see broken patterns.
- The 2am Question
“If production is down at 2am, would you use our platform or kubectl?”
If they hesitate, you have your answer.
LAST WEEK’S OVER-ENGINEERING HORROR STORIES
You delivered! My inbox exploded with complexity nightmares:
🏆 Winner:
“We built a ‘simple’ wrapper around Helm that required learning our custom DSL, which was basically YAML with different syntax. Training time: 2 weeks. Helm training time: 2 hours.” - Anonymous, FinTech
Runner-ups:
- GraphQL API to manage environment variables
- Blockchain-based deployment approvals (yes, really)
- ML model to predict resource requirements (it was always wrong)
I’ll be sharing more horror stories in the masterclass - plus how to fix them.
THE DEVELOPER EXPERIENCE REVOLUTION
Here’s what high-adoption platforms do differently:
- They optimise for the 90% case, not the edge
Most deployments are boring. Make boring things easy.
- They show, don’t abstract
Developers want to see Kubernetes, just simplified. Not hidden.
- They fail fast and clearly
❌ Error: “Deployment failed”
✅ Error: “Container ‘api’ OOMKilled at 2GB limit”
- They respect developer intelligence
Stop trying to “protect” developers from complexity. Simplify it instead.
YOUR ACTION PLAN: THE PLATFORM TRUST REBUILD
This week, pick ONE:
- Delete one abstraction - Find your most hated wrapper and kill it
- Add one escape hatch - Give developers a “break glass” option
- Simplify one workflow - Take a 10-step process and make it 3
- Expose one truth - Show real Kubernetes errors, not pretty lies
- Ask one question - “What would you change?” Then actually do it
READER QUESTION: “HOW DO I FIX DEVELOPER TRUST?”
“Steve, our developers ignore the platform entirely. They’ve built their own CI/CD in GitHub Actions. Should we force them back?”
No. Study what they built. That’s your version 2.0.
The uncomfortable truth? If developers are avoiding your platform, your platform is the problem, not the developers.
Want to see how to turn rebellion into adoption?
Join my CNCF Migration Masterclass next Tuesday where I’ll:
- Walk through the “Underground Railroad” case study
- Show you how to audit shadow IT productively
- Demonstrate the Platform Empathy Test live
- Give you templates for getting honest feedback
Next session: Tuesday 22nd July, 2pm UK / 9am ET
Limited to 12 platform leaders who are ready for uncomfortable truths.
Reserve Your Free Spot (only 6 remaining) →
THE ADOPTION SCORECARD
After helping 50+ teams, here’s what correlates with high adoption:
✅ Time to first deployment: <30 minutes
✅ Required documentation pages: <5
✅ Custom concepts to learn: <3
✅ Steps to deploy: <5
✅ Time to debug an error: <10 minutes
Count how many your platform fails. That’s your priority list.
Bring your scorecard to the masterclass - I’ll help you prioritise what to fix first.
WHAT’S COMING NEXT WEEK
Issue #004: “The Day We Deleted Half Our Platform (And Everything Got Better)”
- The 50% rule that transforms platforms
- Which components are actually critical
- Your platform deletion checklist
Plus: Live platform deletion in the masterclass. Yes, really.
P.S. The most common email this week: “Our platform team read Issue #002 together. We deleted our service mesh.” Keep the success stories coming!
P.P.S. Want to know what your developers really think? Forward them this email with one question: “How accurate is this?” Their reaction will tell you everything. Then bring their feedback to the masterclass - we’ll create an action plan together.
📅 NEXT MASTERCLASS: Tuesday 22nd July, 2pm UK
Topic: The Developer Experience Revolution - Live Platform Empathy Testing. Save Your Free Spot (only six remaining) →