I see this happen almost every week.
A new engineer joins your team. It is day one. They pull a repo and run a deploy script. Suddenly, red text explodes across their terminal. Error: exit code 1.
They check the logs. It is 4,000 lines of unformatted JSON. They ask for help in Slack. A senior engineer replies: "Just set the KUBECONFIG context. Check the wiki."
The wiki hasn't been updated since 2023.
This isn't just a bad onboarding experience. This is a failure of platform product design.
We spend millions building Internal Developer Platforms (IDPs). We use the best tech: Kubernetes, Backstage, Terraform. But we forget the most critical component in the stack. We forget the human being trying to use it.
This is the empathy gap. It is why your expensive platform has low adoption.
A lesson I learned the hard way
I used to build these platforms myself. I thought exposing every API made them powerful. I was wrong.
I was building for machines, not for people. If a developer needs a Kubernetes PhD to deploy a service, I failed them. That realization changed how I think about platforms entirely.
Cognitive friction: The speed killer
In platform engineering, we talk about "golden paths." But a path isn't golden if it's covered in broken glass.
Developers switch between five tools to deploy a hotfix. This creates cognitive friction. Friction isn't just annoying. It is expensive. Every time a developer hesitates or deciphers a cryptic error, their flow state breaks.
A backend engineer should not need deep Kubernetes knowledge to get a URL for their service. If your platform demands that, your abstraction has failed.
Treat platforms like products
When you open Netflix, you don't configure video codecs. You just press play. Your IDP should feel exactly the same.
Why do developers love tools like Vercel or Netlify? Because they are visual. When a deploy fails, they show a clear red line on a graph. Not just a wall of text.
Enterprise platforms often operate as black boxes. You push code. Magic happens. Or it breaks. When the magic breaks, developers feel helpless.
To close the empathy gap, invest in visual engineering:
- Don't just show logs. Show a pipeline graph that highlights where it broke.
- Stop showing CrashLoopBackOff. Show: "App crashed 5 times in 1 minute. Check memory limits."
- Give developers a status dashboard. A control center for their services.
Clarity brings confidence. Confidence brings speed.
Moving beyond DORA: The "joy" metric
We are obsessed with DORA metrics. Deployment Frequency. Lead Time for Changes. These measure speed. They do not measure pain.
You can have a high deployment frequency with miserable developers. Developers who are burnt out from fighting the tools every single day.
To build a world-class platform, measure developer sentiment. Ask your users directly:
- "How frustrating was this deployment, from 1 to 10?"
- "Did the platform help you debug this, or did it get in the way?"
This is your Net Promoter Score for the platform. If your DORA metrics are green but your NPS is red, you have a problem. You built a feature factory, not a product.
UX is infrastructure
There is a common misconception that UX is only for frontend designers. In 2026, UX is infrastructure.
A well-designed CLI flag is UX. A clear error message is UX. A documentation page that actually works is UX.
We need to stop hiring only backend engineers for platform teams. We need product designers and frontend engineers who understand developer workflow.
Conclusion: make the invisible visible
Platform engineering shouldn't hide complexity. It should manage it with empathy.
Bridge the gap between "works on my machine" and "works in production." Respect the developer's time and mental energy.
The next time you build a platform feature, pause. Don't just ask "Does it work?"
Ask: "How does it feel?"
If it feels like a struggle, nobody will use it. But if it feels like magic? You won't have to mandate adoption.
They will beg for access.
