Developer Experience Is a Product — You Just Don’t Have a Product Manager for It

It was 2:47 on a Thursday and Egg hadn’t touched his keyboard in twenty minutes. He sat there, arms folded, vinyl floor cold under his desk shoes, watching a CI pipeline crawl through its fourth run of the afternoon. The air conditioning hummed its flat, permanent note — the one you stop hearing after a month but somehow notice the moment it cuts out. He’d made a small backend API change. Four lines of code. By day one, he’d said he’d be done by end of day. By day four, he’d given up trying to run it locally altogether. His loop was now: push to Git, wait twenty to forty minutes for CI feedback, read the error, push again. Somewhere across the open-plan floor, someone laughed at something on Slack, and the sound landed like salt on a wound.

That’s not a productivity problem. That’s a product problem. You just don’t have anyone whose job it is to see it that way.

As W. Edwards Deming — the man who reshaped how we think about quality in manufacturing — put it: “A bad system will beat a good person every time.” Egg wasn’t slow. Egg wasn’t junior. Egg was a competent engineer trapped in an environment that had never been designed for him. And here’s the part that should make you uncomfortable: every engineering organisation has dozens of Eggs. You probably are one. I know I’ve been one.

We obsess over the products we ship to customers. We measure their journeys, instrument their friction, A/B test their onboarding flows, and God help the PM who doesn’t have a funnel dashboard. But when it comes to the people who build those products? We hand them a Confluence page that was last updated during the previous coup d’état, a Docker setup that works on exactly one person’s laptop, and a pipeline that takes longer than a lunch break. Then we wonder why velocity is declining.

Developer Experience isn’t a collection of engineering chores. It’s a product. It has users, it has friction, it has measurable outcomes, and right now, most organisations are shipping the equivalent of an app that crashes on launch and calling it good enough. And if you’re still wondering where all the time goes, the elephant in your Scrum room is sitting on it.

The North Star You Already Understand

Here’s a test: if someone joins your company on a Monday morning, can they push code to production by end of day?

That question makes most engineering leaders flinch, because the honest answer is measured in weeks, not hours. But it’s the right question, because it reframes everything. It’s not about onboarding documents or Jira ticket templates or “who should I ask about X.” It’s about whether your systems, your tooling, your documentation, and your automation actually work end to end for a real human being sitting at a real desk.

The micro version of the same idea is what I’ve started calling the F5 Experience: clone the repo, open it in your IDE, press F5, and it runs. That’s it. That’s the entire bar. And most teams can’t clear it.

The legendary football manager Bill Shankly once said: “The socialism I believe in is everybody working for the same goal and everybody having a share in the rewards.” Swap “socialism” for “developer experience” and you’ve got the argument. DevX isn’t a perk. It’s the shared infrastructure that determines whether everyone on your team can actually do the work they were hired to do. When it’s broken, some people figure out workarounds, some people suffer in silence, and some people — the ones you most want to keep — start updating their LinkedIn.

The Four Surfaces of the DevX Product

If you’ve ever built a customer-facing product, you already know how to think about this. You’ve just never applied it internally. Developer Experience breaks down into five surfaces, and every engineering organisation I’ve worked with is failing at least two of them.

The Inner Loop

This is the one we’re missing most badly, and it’s the one that matters most. The inner loop is the time between saving a file and seeing the result. It’s your developer’s heartbeat. When it’s fast — sub-second hot reload, instant test feedback — engineers are in flow. When it’s slow, they context-switch. They open Slack. They check their phone. They lose twenty minutes of cognitive momentum to a three-minute compile.

We actually built instrumentation to measure this. Not surveys, not gut feeling — actual timing data from file change to browser render, the same way a product team measures time-to-interactive for their users. And we open-sourced it, because if you’re going to talk about measuring DevX, you should put your tools where your mouth is:

devfeedback-js — Build time and HMR metrics collection for JavaScript/TypeScript bundlers. Plugins for Vite, Webpack, and Rspack/Rsbuild. Drop it into your bundler config and it starts reporting actual compilation times. It also tracks bootstrap chunk sizes, so you can catch regressions before your developers do.

dotnet-build-metrics — The .NET equivalent. A custom MSBuild task that measures build time, application startup time, and test execution duration for every project in your solution. Install the NuGet package and it starts publishing metrics — build times, startup times, test times. It’s a Fitbit for your F5.

java-local-metrics — Test execution metrics for JVM languages. Captures detailed information about JUnit and ScalaTest runs — execution time, pass/fail status, system resource usage during tests. Add the Maven or Gradle dependency and a JVM argument, and your test suite starts reporting back. Supports Java, Kotlin, and Scala.

The finding that surprised people wasn’t the numbers themselves; it was that it was measurable at all. For years, “the dev environment is slow” had lived in the category of complaints that everyone agreed with but nobody quantified. Once you instrument it, it stops being a feeling and starts being a metric. And once it’s a metric, you can improve it.

The Outer Loop

The outer loop — your CI/CD pipeline — gets more attention because it’s more visible. But a forty-minute pipeline means you’ve already lost the inner loop battle. If engineers are pushing to CI just to find out if their code works, that’s not continuous integration. That’s batch processing with extra steps.

The Setup Experience

We ran an event we called the Onboarding Olympics — a competition where engineers from outside our area tried to set up our repos from scratch using only the README. No questions allowed. No Slack messages to the team. Just the README and twenty minutes on the clock.

The rules were simple: contestants had twenty minutes to get as far as possible, using only the README. We scored incrementally — clone the repo, install dependencies, compile, hit a breakpoint on both client and server side. We deliberately picked engineers from adjacent areas who knew similar tech stacks — C# backends, React frontends — so the exercise was fair. This wasn’t about testing their skills. It was about testing our product.

The results were humbling.

What surfaced was a pattern, not a list of individual bugs. Missing install instructions for tools the README assumed you already had. Screenshots showing one IDE while contestants opened another — because people don’t read instructions the way you think they do. Documentation referencing infrastructure the team had replaced months ago, sending contestants down debugging rabbit holes that shouldn’t have existed. OS-specific differences nobody had caught because the whole team used Macs. And repos where the fastest path to “working” went through a shared QA environment — which technically worked but bypassed local development entirely. That’s not a setup experience; it’s a cheat code.

The exercise took an hour and surfaced more about our developer experience than six months of retros had. We run it roughly twice a year now — a recurring external audit that keeps DevX visible. Think of it as usability testing, except your users are engineers and your product is your repo.

The Automation Layer

Every manual step in your developer workflow is a feature request that hasn’t been built yet. If that framing seems aggressive, consider: if a customer had to SSH into a server, run a script, and manually restart a service to complete a purchase, you’d call that a critical bug. When your engineers have to do the equivalent to deploy, we call it “the process.”

The gap between “automated” and actually automated is where enormous amounts of engineering time quietly disappear. A CI pipeline that requires manual approval for non-breaking changes isn’t automated — it’s a queue with a human bottleneck. A deployment script that works only if you remember to set three environment variables first isn’t a deployment script — it’s a README in disguise.

The Documentation Surface

Here’s a truth that product teams understand intuitively but engineering organisations keep forgetting: documentation that’s wrong is worse than documentation that’s missing. A missing feature disappoints. A broken feature actively harms. When your getting-started guide confidently describes a setup process that was replaced six months ago, every new engineer who follows it wastes hours before discovering the betrayal. That’s not a documentation problem. That’s a bug in your product, and it’s shipping to every new user.

You Already Know How to Do This

This is the part where I’m supposed to tell you something new, but I’m not going to. Because you already know all of this. You just haven’t connected the dots.

You measure customer journey time — measure developer journey time. You instrument user behaviour to catch pain points — instrument your build pipeline and IDE performance. You run usability tests with customers — run Onboarding Olympics with engineers. You have SLOs for customer-facing services — have SLOs for CI reliability. You have a product manager prioritising customer features — who’s prioritising the developer’s feature backlog?

The chef and restaurateur Danny Meyer — the man behind Shake Shack and Union Square Hospitality Group — built his entire philosophy around a simple idea: “The only way a company can grow, stay true to its soul, and remain consistently profitable is to attract, hire, and keep great people.” He wasn’t talking about software. He was talking about restaurants. But the principle transfers perfectly: your developer experience is your retention strategy for the people who build everything else.

We surveyed hundreds of engineers across dozens of teams to quantify the cost of flaky CI pipelines. The maths was blunt: when each engineer loses a couple of hours per week to flaky tests and broken pipelines, at scale that adds up to roughly thirty developer-days per month. Convert that to fully-loaded cost and you’re looking at six figures of lost productivity every month. If your customer-facing product had a bug costing that much, it would be in the next sprint. Your developer-facing product has that bug and nobody’s filed the ticket.

Turning Pain Into a Number the Business Understands

The reason DevX improvements struggle for prioritisation is that their costs are diffuse and their benefits are invisible. Nobody sees the thirty minutes an engineer loses to a slow build. Nobody counts the hours a new hire spends deciphering a README that was written by someone who already knew the answers. The pain is real but silent, which means it loses every prioritisation battle against a feature with a revenue number attached to it.

So we started expressing lost developer time in FTE — Full-Time Engineer equivalents. One FTE is roughly 173 productive hours per month. The formula is straightforward: how often does the problem happen, how long does each incident cost per affected developer, how many developers does it affect. Multiply, divide by 173, and you get the FTE equivalent of your pain.

In one area, local development depended entirely on shared QA environments. When QA went down — which happened regularly — developers were blocked. We ran the numbers across three scenarios. The realistic one came out to about 1.5 FTE per month lost to QA environment outages alone. That’s before counting data corruption, context switching, or the momentum cost of breaking someone’s concentration.

Here’s why this matters for planning: 1.5 FTE freed doesn’t mean you hire 1.5 fewer people. It means you can redeploy that capacity — move engineers onto new projects without adding headcount, or keep the same team and raise the bar for what they can deliver. Leadership already thinks in FTE. When you can say “this DevX project recovers 1.5 FTE per month,” you’re speaking their language. You’ve translated a developer complaint into a business case.

Use DORA metrics — deployment frequency, lead time for changes, mean time to recovery, change failure rate — to establish baselines and prove improvement. And when it comes to monitoring what actually matters, make sure you’re asking the right questions about your production systems too.

The Inner Loop Deserves Its Own Paragraph (And Its Own Dashboard)

I want to come back to the inner loop because I think we’re collectively under-indexing on it. Most DevX conversations focus on the outer loop — CI pipelines, deployment automation, infrastructure. These are important. But the inner loop is where your engineers live, eight hours a day, every day.

Think about it from a product perspective. If your customer-facing app had a three-second delay between every click and its response, you’d declare a performance emergency. You’d instrument it, you’d profile it, you’d fix it. Your developer’s inner loop — the time from saving a file to seeing the change — is the equivalent interaction. When it’s fast, they iterate quickly, experiment freely, and catch bugs early. When it’s slow, they batch changes, skip testing, and push larger, riskier commits. Slow inner loops don’t just waste time. They change behaviour, and not for the better.

We built a plugin that measures the actual time from file save to browser render. Not the bundler’s self-reported time — the real, end-to-end developer experience. It was a trivial amount of engineering effort, and it gave us something we’d never had before: actual data on the thing developers complain about most. The gap between what tools report and what developers experience turned out to be significant, which is exactly the kind of finding you only get when you instrument reality instead of trusting dashboards. If you want to see what this looks like in practice — real numbers from real teams comparing Rspack and Vite — I wrote about the results of using this instrumentation in anger.

So Do You Need a DevX Team?

Maybe. Some organisations do. ByteDance reportedly has a team of about eight people supporting roughly three thousand engineers. Google’s ratio skews even higher on the DevX side. Not all of them call it Developer Experience — some call it Developer Tooling, some call it Developer Efficiency. That last one is probably the easier sell to the business, if we’re being honest about how budgets work.

But you don’t necessarily need a dedicated team to start. What you need is ownership. Someone — a person, a rotation, a responsibility — who looks at the entire developer journey from “I joined the team” to “I shipped confidently” and asks the same questions a product manager asks: who are our users, what are their pain points, how do we measure improvement, and what do we build next?

In a world with ten scrum teams and hundreds of engineers, the ROI on DevX investment is enormous because every improvement multiplies across every team. A one-minute reduction in build time across a hundred engineers isn’t one minute saved. It’s a hundred minutes saved, every build, every day.

As the architect Dieter Rams — the man whose design principles Steve Jobs borrowed for Apple — put it: “Good design is as little design as possible.” The best developer experience is the one you don’t notice. You clone, you run, you debug, you ship. No friction, no workarounds, no tribal knowledge, no asking Sarah because she’s the only one who knows why the service does that thing on Tuesdays.

The Bottom Line

Every engineering organisation already has a Developer Experience product. Most just don’t know it. It’s the undocumented, unmeasured, un-owned collection of tooling, automation, documentation, and workflows that determine whether your engineers spend their time building software or fighting the environment that’s supposed to help them build software.

The fix isn’t a rewrite. It’s a reframe. Stop treating slow pipelines, broken documentation, painful onboarding, and missing automation as separate, disconnected annoyances. Start treating them as features in a product that has users, feedback loops, metrics, and iteration cycles. If you’re wondering why Scrum has no handle for this, that’s because it was never designed to — which is exactly why someone needs to own it as a product.

The next time an engineer tells you the developer environment is painful, don’t nod sympathetically and put it in the backlog behind forty-seven feature requests. Ask yourself: if a customer told you the same thing about your product, what would you do?

Now, if you’ll excuse me, I need to go update a README. Apparently it still references a Docker Compose setup we replaced with TestContainers four months ago. But at least our customer-facing onboarding flow has been A/B tested.