I spend a lot of time thinking about developer experience—probably because I came from design where we obsess over user experience. And I keep seeing this pattern: Platform teams build what they think developers need, not what developers actually want.
The promise of platform engineering is compelling: Golden Path that reduces cognitive load by 50%. Self-service infrastructure. Developers focus on features, not on configuring Kubernetes.
But here’s my uncomfortable question: Are we measuring whether developers actually feel that cognitive load reduction? Or are we just assuming our platforms help?
The Design Systems Lesson I Keep Repeating
When we built our design system 3 years ago, we made a classic mistake:
What we built: Comprehensive component library with every possible configuration option. Beautiful, flexible, technically impressive.
What we thought: Designers will love this! So much power!
What actually happened: 40% adoption rate. Most designers kept building custom components.
Why: Our system was TOO flexible. Designers spent more time figuring out configuration than just building the component themselves.
The fix: Simplified to 3 variants per component. Removed 80% of configuration options. Made the default option obviously the right choice for 90% of use cases.
Result: 85% adoption. Designers happy. Cognitive load actually reduced.
The Platform Engineering Parallel
I’m seeing platform teams make the same mistake:
What they build: Powerful, flexible infrastructure platform with lots of configuration options
What they think: Developers will appreciate the flexibility!
What actually happens: Developers confused by options, stick with what they know, platform adoption is middling
What might work better: Opinionated defaults. One obvious way to deploy. Escape hatches for edge cases, but 90% of use cases work with zero configuration.
Platform as Product: Are We Doing User Research?
Michelle mentioned hiring a Platform PM. I LOVE this. Because platforms are products, and products need product management.
But here’s what I want to know: What user research is that PM doing?
When I do user research for design systems, I ask developers:
- What parts of building UI frustrate you most?
- Show me your workflow—where do you slow down?
- What would “easy” look like?
- What stops you from using the design system?
For platform teams, equivalent questions might be:
- What infrastructure tasks waste your time?
- Show me how you deploy a service—where do you get stuck?
- What would “easy deployment” look like?
- What stops you from using the platform golden path?
My hypothesis: Many platform teams aren’t asking these questions. They’re building infrastructure they think is helpful, then measuring success by “did we build it?” instead of “are developers actually happier?”
Measuring What Actually Matters
Keisha mentioned developer satisfaction scores (6.2 → 8.4). I want to see MORE of this.
Platform teams should track:
Adoption metrics:
- % of teams using platform (vs manual infrastructure)
- % of deployments using golden path (vs custom scripts)
- % of new services bootstrapped with platform templates
Happiness metrics:
- Developer satisfaction with infrastructure (quarterly survey)
- “How easy is deployment?” (1-10 scale)
- “How much time do you spend on infrastructure vs features?” (time tracking)
- Net Promoter Score for platform: “Would you recommend our platform to other developers?”
Behavior metrics:
- Support ticket volume (if platform is self-service, tickets should drop)
- Time to first deployment for new services
- Time to productivity for new engineers
If you’re building a platform but not measuring developer happiness, you might be optimizing for the wrong thing.
The Question I’m Sitting With
Luis mentioned “golden path is default, not mandatory—provides escape hatches” and I think that’s the right philosophy.
But in practice: How do you design escape hatches that don’t become the primary path?
In design systems, we provide escape hatches for truly custom components. But some designers use escape hatches for everything because they don’t trust the system.
Platform engineering same risk: If developers don’t trust the golden path, they’ll use escape hatches for everything, and you lose the standardization benefits.
The solution I think works: Make the golden path SO OBVIOUSLY EASIER that escape hatches feel like extra work.
Example from our design system:
- Using system component: 1 line of code, instant preview, automatic accessibility
- Building custom: 50 lines of code, manual accessibility testing, no preview
Guess which one developers choose?
For platforms: If golden path deployment is 2 clicks and custom deployment is 2 hours of Terraform, developers will choose golden path. But if golden path is 10 configuration fields and custom is “copy what I did last time,” custom wins.
The Controversial Take
Platform teams should spend 50% of their time on user research and developer experience, and 50% on infrastructure implementation.
Most platform teams I see: 5% user research, 95% building.
Result: Technically impressive platforms with mediocre adoption.
What I’d love to see more platform teams do:
- Weekly developer feedback sessions
- Observation studies (watch developers use platform, note where they struggle)
- A/B testing different UX approaches
- Measuring cognitive load (time to complete tasks, error rates, satisfaction)
- Treating low adoption as a UX problem, not a training problem
For platform teams: Are you building FOR developers or WITH them? How often do you actually talk to the developers using your platform?
Because reducing cognitive load is the promise. But if we’re not measuring it, we don’t know if we’re delivering.