TCP #102: What does your platform produce when a developer does the minimum?
That answer is your real DX score.
You can also read my newsletters from the Substack mobile app and be notified when a new issue is available.
Most platform teams frame developer experience as a friction problem.
Developers are slowing down. Onboarding takes too long. The internal tools are clunky. Engineers complain about the deployment process.
The answer, in this frame, is to reduce friction. Simplify the interface. Add documentation. Run enablement sessions. Make it easier.
That frame is not wrong. It is just incomplete.
And the part it is missing is the part that actually determines whether your platform produces reliable, compliant, secure software at scale.
SATISFACTION IS NOT AN OBJECTIVE
Developer experience, as most platform teams describe it, is about developer satisfaction.
Are engineers happy with the tools? Is the onboarding smooth? Does the internal developer portal have good UX? Are NPS scores improving?
These are real questions.
Platforms that ignore them produce friction that slows engineers down and drives adoption toward workarounds.
But satisfaction is an outcome. It is not an objective.
Building toward satisfaction without a more precise goal produces platforms that are pleasant to use and dangerous to operate.
THE PLATFORM ALLOWED IT
The satisfaction frame has a hidden assumption: that developers know what good looks like.
Sometimes they do. Slow pipelines, brittle test environments, and manual provisioning steps are real friction points. Engineers identify them accurately, and reducing them produces genuine speed gains.
But the gaps that cause incidents, compliance failures, and cost spikes are not usually friction gaps.
They are judgment gaps.
Engineers make reasonable local decisions that are wrong at the system level. They deploy without tags because tagging was never enforced. They skipped security scanning because the scanner was optional. They provision resources outside the approved account structure because nobody blocked it.
In each case, the developer experience was fine. The path of least resistance was right there.
The problem is that the path of least resistance led to a place the platform should never have allowed.
When you optimize purely for satisfaction, you optimize for ease of use. You do not optimize for correctness.
And in regulated environments where one misconfigured resource triggers a compliance finding, correctness is the product.
THE DEFAULT IS THE PRODUCT
Developer experience is not a UX problem. It is an architecture problem.
The question is not “how do we make this easier?”
The question is “what does the platform make the default, and is the default correct?”
A well-designed platform makes the secure path the obvious path. It makes the compliant choice the low-friction choice. It makes the tagged resource, the approved account, the scanned image, and the reviewed deployment the default.
Developers do not fight the platform. They follow it.
And when they follow it, the output is correct without the developer having to know why.
This is the reframe.
Developer experience, done right, is not about removing barriers to doing things. It is about removing barriers to doing the right things, while adding barriers to everything else.
COMPLIANCE IS DEVELOPER EXPERIENCE
When you adopt this frame, the platform roadmap looks different.
You stop treating developer experience as a track that runs parallel to security and compliance.
You recognize that those things are developer experience.
Making it fast to deploy to a compliant environment is better DX than making it fast to deploy anywhere.
Making it automatic to produce audit evidence is better DX than making it easy to skip steps.
Making it impossible to provision an untagged resource is better DX than making manual tagging easy.
The team conversations change, too.
When a developer asks, “Why do I have to go through this process?” the answer is no longer “because compliance requires it.”
The answer becomes “because the platform ships this for you, so you do not have to think about it.”
One is bureaucracy. The other is product design.
Metrics shift as well. Satisfaction scores remain useful signals, but the primary question is: what percentage of deployments follow the golden path, and what percentage deviates?
Deviation rate is a developer experience metric.
High deviation means the default is wrong. Low deviation means you have built a platform that makes correct behavior the easy choice.
In regulated industries, that metric matters more than NPS.
A satisfied developer who routinely sidesteps the guardrails is a liability. A developer who follows the platform without friction is an asset.
TRACE THE PATH OF LEAST RESISTANCE
Audit your platform for the path of least resistance.
Pick one workflow that your developers do every week. Trace the easiest possible route through it.
Ask: if an engineer does the minimum required to complete this workflow, what does the output look like?
Is it tagged? Is it scanned? Is it in the right account? Is it documented?
If the answer is no, the platform has a developer experience problem.
Not because it is too slow or too hard. Because the default produces the wrong thing.
Fix the default before you improve the UX.
Speed is easy. Predictability is hard. I build platforms that deliver both.
The Cloud Playbook publishes every Wednesday and Sunday. If this issue reframes something you have been thinking about, forward it to one platform leader who is solving DX by improving their portal instead of their defaults.
P.S. This article is part of a deeper series on AWS cloud cost ownership. Paid readers get the full implementation kit.
Whenever you’re ready, there are 2 ways I can help you:
Free guides and helpful resources: https://thecloudplaybook.gumroad.com/
Get certified as an AWS AI Practitioner in 2026. Sign up today to elevate your cloud skills. (link)
That’s it for today!
Did you enjoy this newsletter issue?
Share with your friends, colleagues, and your favorite social media platform.
Until next week — Amrut
Get in touch
You can find me on LinkedIn or X.
If you would like to request a topic to read, please feel free to contact me directly via LinkedIn or X.