Developer experience as a product

Four numbers are being paid by every engineer in your company, every day.

None of them appear anywhere in your planning.

How long it takes a new person to get a working environment.

How long the build and test cycle runs. How long a change waits for review. How long from merge to production.

They compound in a way that's genuinely hard to intuit.

A build taking twelve minutes instead of three, hit maybe fifteen times a day by twenty engineers, is somewhere around forty engineer-hours a week. That's a full-time person, permanently, and it appears on no budget anywhere.

Worse, the loss isn't really the minutes. A twelve-minute cycle changes how people work. They batch changes. They context-switch while waiting. They stop running things locally at all.

That behavioural effect is the real cost.

Which is why these numbers deserve treating as product metrics rather than as a hygiene item.

The four numbers

Time to first commit for a new engineer. Target: they ship something real on day one.

Covered properly in the onboarding lesson. It belongs here too, because it's the best single proxy for environment health: a new person hits every broken thing at once.

Build and test cycle. Target: under ten minutes for the full pipeline, under a minute for the inner loop an engineer runs while working.

Above roughly ten, people stop waiting and start multitasking, and the cost jumps.

Review latency. Target: under a day.

Usually the biggest queue in the system, covered in the WIP lesson, and a developer experience number as much as a flow number.

Merge to production. Target: under an hour, automatically, no human steps.

This one is also your ability to fix things quickly, so it's a reliability number wearing a productivity costume.

Measure all four. Publish them. Track the trend rather than the absolute.

Every one degrades continuously unless something pushes back, because each individual addition to the pipeline is justified and small.

Paved roads that are genuinely easier

The principle separating working developer experience from a compliance layer.

The supported path has to be the easiest path. Not the mandated one.

If your standard way to create a service takes an hour and the shortcut takes ten minutes, engineers take the shortcut. You discover this eighteen months later, during a security review.

Mandating the standard way just moves the workaround somewhere less visible.

So the offer should be simple.

Use the paved road and you get the pipeline, the monitoring, the alerting, the secrets management and the deploy, all working, in minutes. Go your own way and you can, and you own every bit of it.

The test is whether an engineer who dislikes process still takes the paved road, because it's faster.

If they only take it because they have to, it isn't paved. It's a toll booth.

Who owns it before there's a platform team

Under thirty engineers, developer experience is nobody's job, which means it's the thing that gets worse every week while everyone agrees it matters.

The arrangement that works at that size is a rotation with a name and a slot. One engineer, one week in every four or six, whose job is explicitly the four numbers plus whatever is currently annoying everyone. Not a side project. Their actual assignment that week, with their other work reassigned.

Two things make it work. A visible list that anyone can add to, so the rotation isn't guessing. And a report at the end of the week saying what changed, which is what keeps the list being fed.

What doesn't work is "everyone should fix things as they go." That's true and it doesn't happen, because a person mid-feature who hits a slow build will work around it in two minutes rather than fix it in two days. The whole point of the rotation is to create someone whose current job is to take the two days.

Making the case in money

Engineering leaders lose this argument by making it about developer happiness, which sounds like a request for comfort. Make it arithmetic instead.

Take the build time number. Multiply by how many times a day it runs, by the number of engineers, by the number of working days. Convert to engineer-months. Then state what the improvement would cost in engineer-weeks.

"Our build is nine minutes. Twenty engineers run it a dozen times a day. That's around two full-time engineers of waiting. Fixing it is four weeks of one person's time, and it pays back in about six weeks." Nobody argues with that. It's the same conversation as any other investment, and it's the only version that survives a tight quarter.

The one thing to be careful about: don't promise the recovered time as new feature output. Some of it comes back as fewer context switches and better work, and some of it just evaporates. Overclaiming here is how the next developer experience proposal gets treated as engineering asking for a holiday.

What decays, and how fast

Developer experience is not a project you complete. It's a garden, and three things reliably grow back.

Test suites get slower, always, because every test added is small and the total is nobody's responsibility. Set a budget, fail the build when it's exceeded, and make exceeding it a conscious decision.

The environment drifts from production, and the gap grows until "works locally" stops meaning anything. This is the case for ephemeral environments per change, which is a subject of its own in the pipeline lesson.

And the setup docs go stale, invisibly, because nobody who already has a working environment ever runs them. The only reliable detector is a new hire, which is why their frustration is data rather than noise.

The thing to check this month

Ask three engineers what wastes the most of their time. Don't offer options.

You'll get the same two or three answers, they'll be specific, and at least one of them will be something you had no idea about. That list is more accurate than any dashboard you could build, and it costs you fifteen minutes.