I used to think Developer Experience was a polite name for “make the engineers happier.” Stickers. A nicer wiki. A lunch-and-learn about the new pipeline.
Then I watched a principal engineer spend forty minutes finding the correct way to stand up a preview environment — not because they were slow, but because the organization had six unofficial ways and one official way that nobody trusted.
That is not a happiness problem. That is a cognition problem.
The tax nobody puts on a slide
Every time an engineer leaves the problem they were hired to solve and goes hunting — for the right workflow file, the right Terraform module, the right person who “knows how we deploy this” — you are taxing expert attention.
Experts are expensive. Not because of salary, though that is real. Because of scan path. They see structure first. They jump to the contract, the failure domain, the rollback story. Then they dive.
A bad platform inverts that order. It forces them to read linearly through tribal knowledge, stale READMEs, and Slack archaeology. Novices do this by necessity. Experts should not have to. When they do, they stop being experts and become interns with better titles.
I have spent years studying how experts perceive complex environments. The lesson that keeps transferring to platform work is almost rude in its simplicity: if the structure is not visible, people invent their own. That is how you get twelve ways to deploy the same kind of service.
DevEx is a product
Treat it like one.
An internal developer platform has users, a backlog, failure modes, and a reputation. If the official path is slower than the workaround, the workaround is the product. You just do not own it.
The product questions are the same ones I ask of any system that has to survive contact with production:
- What is the golden path? Not the policy PDF. The sequence a competent engineer can follow on a Tuesday without asking for a meeting.
- What does it promise? Build, test, deploy, observe, roll back. If any of those verbs is a rumor, the path is incomplete.
- How do you see it fail? Pipeline observability is not a luxury. If CI is a black box that turns red, you have built a slot machine with YAML.
- Who is it for? Platform teams that optimize for their own elegance produce museums. Platform teams that optimize for the next team’s first successful deploy produce velocity.
I joined AssetMark to lead Developer Experience and Cloud Platform Engineering with that framing. Wealth management software is not a place where “we’ll figure out the path later” is a strategy. The people shipping it need roads they can trust.
Happiness follows the path
Satisfaction surveys are lagging indicators. If you want to know whether DevEx is working, watch what experts do when they are in a hurry.
Do they use the paved road, or do they open a laptop and reconstruct a private one?
Do they trust the pipeline, or do they re-run it “just to be sure”?
Do they create an ephemeral environment themselves, or do they file a ticket and context-switch into something else for two days?
The answers are the product review. The survey just confirms what the behavior already told you.
Snacks are fine. I like snacks. They do not reduce the cost of a forty-minute hunt for the deploy button.
What I optimize for
I do not optimize for tool count. I optimize for time-to-honest-feedback.
How long from clone to a running environment that looks like production enough to teach you something? How long from pull request to a signal you can trust? How long from “this is wrong” to rollback?
Those clocks are the DevEx scoreboard. Everything else is decoration unless it moves them.
That is why CI/CD, Infrastructure-as-Code, ephemeral environments, and self-service infrastructure show up in the same conversation. They are not separate programs. They are chapters of the same product: make the expert path the easy path.
The leadership part
Platform work dies in two familiar ways.
The first is service-desk theater. The platform team becomes a ticket queue with better branding. Six months later they are the bottleneck they were hired to remove.
The second is cathedral building. A beautiful internal platform that no product team adopts because adopting it is harder than staying on the old road.
The middle path is partnership. Sit with engineering, architecture, product, security, and operations. Translate business needs into capabilities teams can operate without you in the room. If you are still the room, you built a dependency.
This is the same lesson I learned leading GenAI adoption in healthcare. Tools do not transform teams. Credible paths do. Guardrails people will walk. Templates they reuse because they are faster, not because a mandate said so.
A question I keep asking
If an expert joined your organization on Monday, how long until they can ship something they are proud of — without asking three people for the secret map?
That interval is your Developer Experience.
Shorten it, and you do not just make people happier. You return their attention to the work only they can do: judgment under real constraints.
That is the job. Not a perk. A platform.