Writing

2026.05 — 6 min Strategy

Most developer experience design efforts are structured as a usability exercise: reduce friction; polish the docs; shorten the feedback loop; make the first hello world fast. All of this is correct — but all of it might be for naught. That's because it's all subject to a decision the developer might have already made before they touch your platform: whether it is worth committing to at all.

That decision is not a usability question. It is a trust question. Do they trust your platform — and your company — to know what their product needs, and to deliver it? This is the part of developer experience that teams most reliably fail to design for, because it does not show up in a funnel and it does not have an obvious owner.

The commitment a developer makes beyond what they experience

When a developer evaluates a platform, they are not only asking whether the API is pleasant. They are asking whether to route their project, their quarter, and maybe even their professional reputation through your technology. Adopting a platform means learning its idioms, accepting its constraints, and tying one's delivery timeline to your roadmap and your reliability. If the platform stalls, deprecates aggressively, or turns out to be less mature than its marketing implied, the developer absorbs that cost — sometimes personally.

So before friction matters, clarity of purpose matters. A developer who does not trust the platform will not stay long enough to notice that you shaved two seconds off the build. Trust is the precondition that makes every other DX investment legible. Design it last and you are optimizing an experience most of your prospective developers have already declined.

Why trust became a focus

I learned to take trust seriously while working on Predix, GE's industrial IoT platform. The stakes were unusually high. The platform was new, the company was not known for developer software, and the developers evaluating it were industrial engineers deciding whether to bet real operational systems on an unproven foundation. I ran dozens of interviews with new and aspiring Predix developers, and the deepest question underneath their stated pain points was rarely "how can I do X" (though that came up a lot). What they really wanted to know was "should I rely on this platform?" We decided to open up more about what we were building, and put this in front of developers, so they could invest with us as we built the platform.

Starting with trust was an equally relevant insight when I helped design the Digital Experience Monitoring platform at AppDynamics and later at Splunk. Developers come to these platforms because they can handle the scale and speed necessary to measure user experience for millions of users across varied suites of browser and mobile apps. Sometimes we faced a decision in how certain measures and aggregations were calculated — and presenting the data as simple facts raised the specter that we weren't getting every calculation right. Ensuring that every number we showed immediately made intuitive sense to the developer users was more important than all the new features we could cram into the roadmap. Because if we didn't convince them that our core observability metrics were correctly measured, aggregated, and displayed (even when they didn't understand all the details of how it should be done) — then no amount of futuristic automated predictions and analysis would be reliable either.

Reframing from simply making things polished and easy to really getting the developers' buy-in changed what the design team was solving for. We were not only removing obstacles and making workflows simpler. We were earning a commitment, repeatedly, at every moment where the developer has an option to consider a competitor.

Trust is not one move — it's a journey

Another mistake is to imagine trust as a single impression formed at the landing page. It is not. It is re-earned, or lost, at each stage of the developer's path, and it requires a different action at each one.

When a developer is exploring whether the platform fits, trust means being transparent about what the platform is and, just as importantly, what it is not. Overclaiming here is the fastest way to forfeit credibility with exactly the sophisticated developers you most want.

When they move to experimenting, trust means being honest about platform maturity. Developers can work around a rough edge they were warned about. They cannot forgive one they were allowed to discover at the worst possible moment.

When they build, trust means intelligent defaults and conventions that hide complexity without lying about it. Convention over configuration is a trust mechanism, not only a convenience: it signals that the platform's authors have already made the hard decisions well, so the developer does not have to audit every one.

When they share work into the community, trust means clear, low-friction paths to contribute and participate, because seeing the community that is building the platform is the first step to joining that community.

And when they manage a live application, trust means visibility into performance and status. Nothing erodes commitment faster than an outage the developer learns about from their own users rather than from you.

Trust demands transparency in one stage, honesty in another, and observability in a third. Attempting to generate trust only with a superficial brand strategy or a single feature is why many tools fail to really connect with their targeted users.

Why teams skip it, and what it costs

Trust gets neglected for structural reasons, not because anyone decides it is unimportant. It has no natural owner: it sits between marketing's claims, product's roadmap, engineering's reliability, and design's touchpoints, and so it falls into the gaps. It is also hard to instrument. You can measure time-to-first-call; you cannot easily measure the developer who quietly concluded you were not a safe bet and left without an event firing.

The cost is paid later and is difficult to attribute. It appears as evaluations that never convert, as developers who try once and do not return, and as a reputation among senior engineers that is expensive to repair. By the time it shows up in the numbers, the design work that would have prevented it is several quarters in the past.

The practical upshot

If you are building a developer tool or a data platform, audit for trust before you audit for friction. Walk the developer's journey stage by stage and ask, at each one, what commitment you are asking for and what you are offering in return that justifies it. Where the answer is not obvious to you, it's probably not to your users either, and you have found a more valuable problem than whatever you were about to optimize.

This is the lens I bring to developer experience: not a checklist of usability fixes, but a sequence of commitments to be earned. This is what determines whether the rest of the work gets a chance to matter.

2026.05 — 6 min Strategy

The first myth is that documentation is the getting-started experience. It isn't. Docs are where a developer goes once they already believe the tool is worth their afternoon — and the experience that earns that belief happens earlier, in the gap between intent and the first thing that actually works.

The second myth is that adoption is a marketing problem. By the time a developer has typed your install command, marketing has done its job. What happens in the next hour is a product problem — and it is usually owned by no one.

Getting-started is the strategic battleground precisely because it is unglamorous. It sits between teams, rarely has a directly responsible owner, and almost never survives a roadmap that an engineering-led org prioritizes by feature. Research changes that by making the first hour legible — turning a vague sense that onboarding "could be better" into a ranked list of specific moments where specific developers gave up, and what each one cost.

That list is the strategy. Everything after it is execution.

2026.04 — 5 min DEM

Digital Experience Monitoring helped expert practitioners diagnose performance and reliability problems in complex enterprise systems. The user was never a casual one. They arrived with a hypothesis, a deadline, and a tolerance for depth that consumer software never has to design for.

That changes what AI features are for. Tag Spotlight auto-summarization, AI-assisted root cause analysis, URL grouping — none of these exist to simplify the tool for a novice. They exist to compress the distance between an expert's question and the evidence that answers it. The measure isn't "easier." It's "fewer steps between suspicion and proof."

This is what consumer UX research tends to miss about the expert practitioner: friction and difficulty are not the same thing. An expert will happily accept a difficult interface that respects their model of the system — and abandon an easy one that flattens it.

forthcoming Draft

Strategic DX for an AI-native dev-tools startup from early stage — the first end-to-end workflow diagram, the Ship Risk metric, and prototypes shipped as merge-ready pull requests. Publishing pending a check on what is shareable.