Good Developer Experience Is Subtraction

Developer experience is one of the highest-leverage things you can manage on an engineering org, and the reason is simple: friction is the largest cost most teams never count. It does not show up on a budget, it does not send an invoice, and it is usually measured in millions of dollars a year. The person who can see that cost, put a number on it, and remove it is doing some of the most valuable work in the building. That role has a name now, and it is a good one to want.

The craft of it starts with a shift in how you look at a slow build or a painful setup. Not as a morale complaint. As a line item.

The ledger you get to write

Take one team and the most ordinary friction there is: the build. Start with the naive ceiling, the number you should never actually quote on its own.

See content credentials

Developers do not sit frozen for nine minutes. They flip to Slack, glance at a PR, refill the coffee. So is the real cost zero? Not close, and the reason is the part worth understanding.

A build in the one-to-ten-minute range is the worst possible length: too long to sit and wait, too short to start anything real. So the developer context-switches, and the cost of an interruption is not the wait itself, it is the ten to twenty minutes of fractured attention before they are fully back in the problem. The nine minutes were never the bill. The bill is a context switch, a dozen times a day, per engineer, and context switches are where engineering time actually bleeds out. Count only the focus you genuinely lose, not the wall-clock, and one slow build still lands in the range of two to four engineers of real capacity a year, on a single team.

There is a second cost the stopwatch misses. When the loop is slow, people batch. They stop rebuilding to check one small thing, they bundle five changes into one push, the PRs grow bigger and riskier, and the cheap experiment nobody bothers to run becomes the bug you ship. A slow inner loop does not only burn time, it quietly makes the work worse.

None of this lands on a line of any budget, because nobody invoices you for a context switch. Friction does not send a bill. Run the same honest accounting on the eleven-minute test suite, the half-day local setup, the deploy that waits on three approvals, and the total on a mid-sized team is real money. That is not a problem to be embarrassed about. It is the opportunity the role exists to capture.

Translation is the superpower

A cost gets managed when something charges you for it. Cloud has an invoice, headcount has a contract, friction has neither. It is paid in thirty-second and nine-minute increments, spread across everyone, attributed to no one. So it lives in soft words: the build is “kind of slow,” onboarding is “painful,” the deploy is “annoying.” Soft words do not win budget. Numbers do.

The DX manager’s first move is translation: turn every “annoying” into an hours-per-year figure, then a salary figure. Once friction carries a dollar sign, it stops being a complaint and becomes what it always was, an operating expense, and a large one you now have a mandate to go reduce. That reframe alone changes the conversation in your favor.

The wins are boring, which is why they are reliable

See content credentials

Here is the satisfying part. Once you have the ledger, the highest-return move is almost never an expensive purchase. It is shaving four minutes off the build. It is deleting a step. It is making the local environment come up with one command instead of a wiki page.

That nine-minute build dropped to four saves more than half the number above, with no new platform to staff and no migration to survive. A profiled build, a cache that actually caches, a dependency graph someone finally pruned. This is unglamorous work that pays better than anything with a logo, and a good DX manager loves it precisely because the return is so clean.

The instinct in the room will sometimes be to buy or build a big developer platform to “fix DX.” Sometimes that is right. Often the boring move beats it, because a platform is a new product with its own surface, its own bugs, its own upkeep, and adding a thing to the system to make the system simpler rarely makes it simpler. The boring move removes; that is its edge. Choosing removal when addition is the flashier story is the judgment the role is really hiring for.

This is the boring-technology argument applied to your own toolchain. Solid beats novel. Engineers feel good developer experience as the absence of friction, not the presence of features, and absence is something you create by taking things away.

The discipline, in three habits

Managing developer experience as a cost line comes down to three habits, none of them fancy, all of them learnable.

Measure the inner loop. The seconds between saving a change and seeing whether it worked are the most expensive seconds a team spends, because they spend them constantly. Build time, test time, hot-reload time, time-to-first-PR for a new hire. Watch those numbers and you are managing the expense with your eyes open.

Price the friction. Every slow thing gets the arithmetic above, not to be exact to the dollar but to rank. The eleven-minute test suite and the half-day setup are not equally bad; the ledger tells you which one is eating more, so that is the one you fix first.

Spend on the boring thing. When the number says the build is costing eight headcount, you put two strong engineers on the build for a month and you state the return plainly. The payoff is measured in the same currency as the cost, and it is large enough to defend in any room.

The signal a strong DX team sends

The thing to bring is a friction ledger. “Our build was costing the equivalent of eight headcount a year, and we cut it in half in six weeks with no new infrastructure” is a sentence that says you see engineering as a business expense, you know which expenses hide, and you know how to remove them cheaply. It pairs business judgment with hands-on technical taste, which is the exact combination the role wants and a genuinely uncommon one.

Developer experience was a number the whole time. The teams that win treat it like one: they count the friction, they price it, and they spend the boring money to make it disappear. Managing that well is a real discipline, increasingly a titled one, and it is a great thing to be good at right now.

I am building Kilnx, a declarative backend language that pairs with htmx, and Provero, where a lot of the judgment-shape decisions I write about are the day job. If the diagnosis here lands, that is the door.

André Ahlert is a product engineer. Contributor across Burr, Airflow, Flyte, Backstage, HTMX, Hyperscript. Currently building Kilnx and Provero.