Platform Engineering Without Developer Experience is Just Ops With a New Name

General
1

I see a lot of platform engineering initiatives fail, and they fail for the same reason most internal tools fail: teams treat them like infrastructure projects instead of product launches.

Let me be blunt: If your platform team’s roadmap is full of technical achievements instead of developer outcomes, you’re building the wrong thing. And if you’re not measuring developer satisfaction with the same rigor you measure system uptime, you don’t actually know if your platform is working.

The Anti-Pattern: Building What Engineers “Should” Want

I’ve watched this play out multiple times. Platform team gets created. Senior infrastructure engineers get hired. They’re brilliant technicians who love Kubernetes, service mesh, observability stacks.

And then they build a platform that showcases all that technical sophistication.

The result? An Internal Developer Portal that looks like a spaceship cockpit. 47 different configuration options. Documentation that assumes you already understand the abstractions. Error messages written for the platform team, not the developers using it.

Six months later, adoption is at 20%. The platform team is confused: “But we built exactly what they asked for!”

No. You built what you thought they asked for. You never actually validated whether the solution solved their real problems.

This Is Product Management 101

Here’s what I tell my platform team: Developers are your customers. Treat them like it.

That means:

  • User research: Interview developers. Watch them work. Understand their actual workflows, not your idealized version.
  • Personas: Your junior developer has different needs than your senior SRE. Design for both.
  • Jobs to be done: What job is the developer hiring your platform to do? “Deploy a service” is too broad. “Deploy a service before standup so I can demo it to the PM” is a real job.
  • Feedback loops: Quarterly satisfaction surveys. Bi-weekly office hours. Visible roadmap where developers can vote on priorities.
  • Adoption metrics: If people aren’t using your platform, it doesn’t matter how technically elegant it is.

The Symptom: IDP Shelfware

Internal Developer Portals are the perfect example. Everyone’s building them right now because Gartner said to. But how many actually get used?

I’ve seen IDPs become shelfware for predictable reasons:

  • They solve yesterday’s problem. The platform team spent 9 months building a deployment portal while developers moved to GitHub Actions.
  • They add cognitive load instead of removing it. “Now I need to learn this portal AND the underlying tools.”
  • They’re optimized for compliance, not usability. Seventeen approval steps for security theater.
  • They lack obvious value. Can’t answer “Why would I use this instead of my current workflow?”

The successful IDPs I’ve seen share one thing: They make developers’ lives noticeably better on day one.

The Question I’m Asking

How do you measure developer satisfaction with your platform?

I’m not talking about vanity metrics like “number of services onboarded” or “percentage of teams using the platform” (which can be gamed by mandates).

I’m talking about:

  • Time saved: Can a developer quantify how much faster they can deploy with your platform?
  • Cognitive load reduced: Do developers report having more mental energy for product work?
  • Frustration removed: What painful manual processes have you automated away?
  • Confidence improved: Do developers feel safer deploying because of your platform’s guardrails?

At my company, we run quarterly developer experience surveys with questions like:

  • “How satisfied are you with the deployment process?” (1-10 scale)
  • “How often do you encounter unexpected issues deploying?” (daily/weekly/monthly/rarely)
  • “If you could change one thing about our platform, what would it be?” (open-ended)

And we track NPS specifically for the platform team: “How likely are you to recommend our platform to another engineer?”

The Challenge

Platform engineering without developer experience focus is just ops with a new name.

You can have the most brilliant technical architecture, the most sophisticated automation, the most comprehensive observability—and still fail if developers hate using it.

For those building platforms: How are you ensuring you’re building what developers actually need, not what you think they should want?

For those using platforms: What makes the difference between a platform you love vs one you tolerate?

I’d love to hear how others are thinking about the product side of platform engineering, because I think this is where most initiatives live or die.

2

David, YES! This is exactly what I’ve been trying to articulate to engineers who think design systems are “just a component library” :artist_palette:

Design Thinking for Internal Tools

What you’re describing is literally design thinking applied to internal tools. And it’s SO needed.

I spent two years building a design system that nobody used because I made the exact mistakes you’re calling out:

  • Built what I thought designers needed (comprehensive, flexible, perfect)
  • Didn’t validate assumptions with actual user research
  • Optimized for completeness over usability
  • Shipped after 18 months when the team had already moved on

The Turnaround: User Journey Mapping

Here’s what finally worked:

Step 1: Shadow real designers for a week
Didn’t tell them what to do differently. Just watched. Took notes on:

  • Where do they get stuck?
  • What makes them swear at their screen?
  • When do they give up and create a “custom” component?
  • What tools do they reach for first?

Step 2: Map the actual user journey
Not the ideal journey in my head. The messy reality:

  1. Designer needs a button variant
  2. Searches Figma library (can’t find what they need)
  3. Searches Storybook docs (overwhelming, unclear)
  4. Asks in Slack (waits 2 hours for response)
  5. Says “screw it” and designs from scratch
  6. Developer codes it as one-off component
  7. Now we have button #48

Step 3: Fix the biggest pain point first
Not the most technically interesting one. The most annoying one.

For us: Search. Nobody could find components because our naming was inconsistent and we had no visual search.

We spent one sprint adding visual search with screenshots. Adoption went from 30% to 60% overnight. Because we removed friction.

Developer Personas for Platforms

David, you mentioned personas—I think this is CRITICAL and often skipped.

For platforms, you probably have:

  • The New Hire Noah: Just onboarded, needs to deploy their first service, terrified of breaking prod, doesn’t know internal jargon
  • The Senior Sophie: Been here 5 years, knows all the workarounds, will revolt if you slow her down, judges tools harshly
  • The On-Call Omar: Gets paged at 2am, needs to debug fast, platform better have good error messages and logs
  • The Compliance Clara: Works in fintech/healthcare, needs audit trails and approval workflows, can’t skip security

Your platform needs to serve ALL of them. Which means:

  • Defaults that work for Noah (simple, guided, hard to mess up)
  • Escape hatches for Sophie (power user mode, skip the wizard)
  • Observable everything for Omar (logs, traces, clear error states)
  • Compliance as a feature for Clara (not bolted on, integrated)

Measuring Success: The “Would You Recommend It?” Test

You mentioned NPS for platforms. I love that. We do the same for our design system.

But I also ask this question in our quarterly survey:

“If you joined a new company, would you miss this [tool]?”

That’s the gut check. If developers would actively miss your platform if they left, you’ve built something valuable. If they’d be relieved to leave it behind, you’ve built technical debt.

The Hidden Metric: Flow State Time

Here’s one more metric I think platforms should track: How much uninterrupted flow time do developers have?

If your platform requires:

  • Constant context switching to different tools
  • Hunting for docs across 5 different wikis
  • Waiting for approvals or manual steps
  • Debugging cryptic errors

You’re killing flow state. And flow state is when developers do their best work.

Good platforms fade into the background. Developers barely think about them because they just… work.

Practical Suggestion

David, your quarterly surveys are great. Can I suggest adding:

Usability testing with new hires

Watch a new engineer try to use your platform for the first time. Don’t help them. Just observe.

Where do they get confused? What assumptions does your docs make that they don’t have? What error messages make sense to you but not to them?

New hire usability testing catches SO much that surveys miss. Because people who’ve been using a tool for months develop learned helplessness—they forget what was initially confusing.

This approach turned my design system around. I bet it would work for platforms too.

3

David, you’re calling out something I lived through painfully.

Our first platform attempt failed exactly like you described. We built in a vacuum, launched with fanfare, and watched adoption stall at 15%.

The turning point was when we hired a product manager for the platform team. Not an engineer who “can also do PM work.” An actual PM with user research skills.

What Changed

Before: Platform team roadmap based on what senior engineers thought was important
After: Platform team roadmap based on developer pain points, prioritized by impact

The PM did two things that transformed everything:

1. Embedded with product teams for a month
She sat with developers. Watched them deploy. Took notes on every friction point. Created a massive pain point inventory.

Top 3 weren’t what we expected:

  • Debugging deployment failures (error messages were cryptic)
  • Finding the right config template (16 templates, unclear which to use)
  • Getting approval for production access (manual process, 3-day wait)

2. Treated platform as a product launch

  • Beta program with 2 friendly teams
  • Weekly feedback sessions
  • Metrics dashboard showing time-to-deploy before/after
  • “Success stories” showcasing wins

Adoption went from 15% to 75% in 6 months. Not because we mandated it. Because we made it genuinely better.

The Metrics That Matter

We track:

  • DORA metrics (deploy frequency, lead time, MTTR)
  • Developer satisfaction (quarterly survey, NPS)
  • Time saved (onboarding time, deployment time, incident response time)
  • Opt-out rate (teams choosing to leave the platform - this is a leading indicator of problems)

The last one is key. When teams opt out, we do exit interviews. Why are you leaving? What would make you come back?

Sometimes it’s legitimate edge cases. Sometimes it’s missing features we should build. Always learning.

Platform teams need to think like product teams. That’s the difference between success and shelfware.

4

This hits at the core of why I restructured our platform team last year.

Platform Team Needs Product Thinking

Here’s what we did differently:

Our platform team now has:

  • 4 platform engineers (infrastructure experts)
  • 1 product manager (full-time, experienced PM)
  • 1 UX designer (shared with product, 50% allocation)
  • 1 technical writer / developer advocate

That investment in PM and UX raised eyebrows with finance. “Why do we need a designer for infrastructure?”

Because developer experience IS user experience. And user experience requires intentional design.

The 20% Rule

20% of our platform team’s time goes to developer experience research:

  • Monthly usability testing with new hires
  • Quarterly satisfaction surveys
  • Bi-weekly office hours for feedback
  • Annual “developer joy” assessment

That 20% investment has 5x ROI in adoption and velocity.

ROI Example: Onboarding

Before platform redesign:

  • Time to first deploy: 2 weeks
  • Required reading: 47 wiki pages
  • Setup steps: 23 manual configuration steps
  • Success rate on first try: 30%

After (with PM/UX leading the redesign):

  • Time to first deploy: 2 days
  • Required reading: 1 interactive tutorial
  • Setup steps: 3 (automated the rest)
  • Success rate on first try: 85%

That change alone saved ~160 hours per quarter in onboarding overhead. For our team of 80, that’s roughly $40K in recovered engineering time quarterly.

The cost of the platform team improvements? ~$30K in PM/UX time.

Net positive in one quarter. Compounding returns every quarter after.

The Mindset Shift

David, you said “platform engineering without DX is just ops with a new name.” I’d go further:

Platform engineering without product thinking is worse than ops. Because at least old-school ops didn’t pretend to care about user experience. Modern platforms that ignore DX create resentment because they promised empowerment but delivered complexity.

Developers are users. Full stop. Treat them with the same rigor you’d treat external customers.

5

I want to add the culture and hiring dimension that often gets missed.

Platform Engineers Need Different Skills

When I first built our platform team, I hired senior infrastructure engineers. Smart people. Great at Kubernetes, networking, distributed systems.

But they built platforms that other senior infrastructure engineers would appreciate. Not platforms that product engineers would love.

The problem: Senior engineers often optimize for technical elegance over usability. They build what impresses their peers, not what helps junior developers ship faster.

What I Look For Now

When hiring for platform teams today, I look for:

1. Empathy over ego
Can they listen to a junior developer struggle with deployment and not say “just read the docs”?

2. Product sense over technical flex
Do they think “how can I make this easier?” before “how can I make this more powerful?”

3. Communication skills
Can they explain complex systems in simple terms? Write docs that humans can actually follow?

4. Service mentality
Do they see themselves as enabling product teams, or as gatekeepers of “the right way”?

I’ve found some of my best platform engineers came from product engineering backgrounds. They understand the workflow. They’ve felt the pain. They build solutions that actually fit.

The Practice: New Hire Usability Testing

Maya mentioned this—it’s gold. Every quarter, we do new hire onboarding observations:

  • Platform engineer sits quietly in the corner
  • New hire tries to deploy their first service
  • We don’t help. We just watch and take notes.
  • Where do they get stuck? What’s confusing? What error message makes no sense?

Then we fix those things. Not “add better docs.” Actually fix the underlying experience.

This practice keeps us honest. It prevents us from developing the “curse of knowledge” where we forget what it’s like to not understand our own platform.

Making It Psychologically Safe

One last thing: Make it safe to say “this platform sucks.”

We have a monthly retro where we ask: “What made you want to throw your laptop this month?”

No defensiveness. No “well actually that’s user error.” Just: “Thanks for the feedback. We’ll fix it.”

Platform teams that can’t handle criticism become ivory towers. Platform teams that actively seek out pain points become invaluable.