Leading a platform team, I think a lot about what it actually means to build good tools for developers and non-developers alike. Not just "does it work”, but does it feel good to use? Does it get out of the way? Do the error messages actually help, or do they make you want to throw your laptop?
That's the heart of DevEx. And it's something most teams underinvest in.
What DevEx Actually Is
Developer Experience isn't just about productivity metrics. It's the sum total of how a developer feels when interacting with your platform, APIs, CLI, docs, and error messages. It's friction. It's flow. It's whether someone can figure out what went wrong without filing a support ticket.
The classic definition focuses on cognitive load: how much mental overhead does a developer carry just to get something done? Lower cognitive load means faster onboarding, fewer mistakes, and happier engineers who actually want to use your stuff.
Where Friction Hides
The tricky thing about DevEx problems is they're invisible until someone shows you. You built the thing, so you know how it works. Your users don't.
Some of the most common places I've seen friction pile up:
Error messages that tell you what broke, not why. "Error 500" is not helpful. "Missing required field userId in the request body" is.
CLI flows that assume too much. If your CLI requires three flags most people have to look up every single time, something's off.
Docs that describe the happy path and nothing else. Real developers hit the unhappy paths constantly.
Finding Your Friction Points
You can't fix what you haven't found. The two tools I keep coming back to are NPS surveys and user interviews.
NPS for developer tooling is underrated. A simple "How likely are you to recommend this tool to a teammate?" question, sent at the right time, surfaces a ton. The open-ended follow-up is where the gold is, it’s where people tell you they've been copy-pasting the same workaround for six months.
User interviews take more time but go deeper. Watch someone use your tool without coaching them. Don't explain anything. You'll see every hesitation, every confusion point, and every place where they go quiet and start guessing. It's uncomfortable and incredibly useful.
Small Changes, Big Gains
Here's something I've noticed: DevEx improvements don't have to be big. Some of the highest-impact changes are tiny.
Rewriting a cryptic error message to actually explain what happened. Adding a --dry-run flag to a destructive CLI command. Putting a realistic example in the docs instead of foo and bar. These things take hours, not sprints, and they compound.
The big platform redesigns matter too, sometimes the architecture itself is the friction. But don't sleep on the small stuff while you wait for the big stuff to get prioritized.
Measuring Whether It's Working
It's hard to measure DevEx directly. There are a lot of metrics and methodolgies out there, like DORA, pipeline delivery, or even focus time. What I think is important to track:
Time to first success: how long until a new user completes their first meaningful action?
Support ticket patterns: are the same questions showing up over and over? That's clearly a friction point.
NPS over time: is it trending up after you ship changes?
Qualitative feedback in interviews: are the friction points you heard six months ago still coming up?
None of these are perfect. All of them together give you a picture.
DevEx is one of those things where the ROI is hard to quantify but easy to feel. When it's good, developers move faster, adopt more, complain less, and build more interesting things with your platform. When it's bad, they find workarounds, write angry tweets, and eventually churn.
It's worth the investment. I promise.