§ CAPABILITY

Developer Experience and Internal Platform

The friction between an engineer having an idea and the change being live. Local setup, build times, environment access — measured, then removed in the order that costs the most.

Who
Delivered by a senior team assembled for the engagement, against a defined scope.
Request a call How the work runs

What you're seeing

A new engineer takes three days to get the application running locally.
Usually means Setup is a sequence of undocumented steps that current engineers have already absorbed. It is the most visible friction in the system and among the cheapest to remove permanently.
Engineers do something else while the build runs.
Usually means Past roughly ten minutes a build stops being feedback and becomes an interruption. The cost is not the minutes, it is the context switch and everything that follows from batching to avoid it.
Getting a test environment requires asking someone.
Usually means Environment provisioning is a human process, so it has a queue and business hours. Every experiment now carries a scheduling cost, which mostly means fewer experiments.
There are three ways to deploy a service and nobody knows which is current.
Usually means There is no paved path, so each team invented one. The cost surfaces when someone has to operate a service they did not build.

Friction compounds

A build that takes fifteen minutes does not cost fifteen minutes.

It costs the context switch out, whatever the engineer did instead, the context switch back, and the accumulated effect of both on how work gets batched. Measured honestly it is closer to an hour a day per engineer, which at any reasonable team size is headcount-scale spending that appears in no budget line and no report.

That is the general shape of developer experience work: individually small frictions, each too minor to raise, whose sum is large and invisible. The reason to measure first is that measurement makes the sum visible, and the sum is the only version of the argument that competes with a roadmap.

Onboarding first

Not because it is the biggest cost, but because it is the honest one.

Existing engineers have absorbed the setup process. They know which environment variable is undocumented, which service has to be started first, and which step to skip. A new joiner knows none of that, which makes their first week the only unbiased measurement of how bad the path actually is.

It is also cheap to fix — usually a containerised environment, a seed dataset, and one command — and the improvement is immediately felt by everyone, which buys the credibility to spend on the less visible items after.

The path has to win on merit

A golden path that is harder than working around it will be worked around, and the usual response is a policy requiring its use.

That response converts a product problem into a compliance problem and then hides it. Adoption stops being a signal, because use is now mandatory, and the platform team loses the only feedback that was telling them something.

The alternative is to treat internal tooling as a product with users who can leave: measure adoption, ask the people not using it why, and accept that low adoption means the path is losing. It also means deciding what is deliberately not supported — internal platforms fail most often by trying to serve every case and serving none of them well.

Where it sits

This capability sits under Platform Engineering, where the paved path is the platform’s actual product, and under Engineering Velocity, where friction is frequently the largest single item in the ranked account of where time goes.

Two neighbours carry most of the fixes. CI/CD Pipeline owns build time and review feedback, which is usually the largest measured item. DevOps Consulting owns environment provisioning and the reproducibility that makes a one-command local setup possible at all.

How the work runs

  1. Measure the friction

    Time to first commit for a new joiner, local setup time, build wait, review latency, time to get a test environment. Numbers rather than impressions.

  2. Fix onboarding first

    A machine productive in hours rather than days. It is the most visible cost and among the cheapest to remove.

  3. Build the paved path

    One well-documented way to create a service, deploy it and observe it. Golden paths only work when the path is genuinely easier than going around it.

  4. Treat internal tooling as a product

    Users, feedback, and a decision about what is not supported. Internal platforms fail by trying to serve every case.

What arrives

  • A friction baseline with numbers against each step
  • A one-command local environment
  • A documented paved path for creating and shipping a service
  • A feedback loop with the engineers who use it

What it costs your team

A survey of your engineers and around three hours a week from a platform-minded lead.

Next step

Tell us where this is breaking and we'll say what it takes to fix.

Request a call

How we decide

  • Friction is measured before anything is changed

    Costs It spends the first stretch of the work producing numbers rather than improvements.

    Developer experience is otherwise a mood, and moods are argued rather than decided. Time to first commit, local setup time, build wait, review latency and time to a test environment are all measurable, and having them means the work can be prioritised by cost and evaluated afterwards. Without a baseline, the only available verdict is whether people feel better.

  • Onboarding is fixed first

    Costs It is not the largest cost in aggregate, so this is not the strictly optimal order.

    It is the most visible, the cheapest to fix, and it is the one piece of friction that is measured honestly — a new joiner has not yet learned to route around it. Fixing it first also buys the credibility to spend on the less visible items afterwards, which is worth more than the strict ordering.

  • The paved path has to be genuinely easier than the alternative

    Costs It means investing in ergonomics for internal tooling, which never competes well against customer-facing work.

    A golden path that is harder than working around it will be worked around, and the response is usually a policy requiring its use — which converts a product problem into a compliance problem and hides it. If adoption is low, the path is losing on merit, and that is the information the work needs.

Frequently Asked Questions

The quality of the path between an engineer having an idea and it being live: setup, build, test, review, deploy, observe. The reason it is worth naming as a discipline is that it is measurable — time to first commit, build duration, review latency — which is what separates it from a general mood about tooling.
Platform engineering builds the internal product. Developer experience is what that product is judged on, and it extends beyond the platform to things a platform team does not own — review latency, documentation quality, meeting load, how long it takes to get an answer.
Rarely. Most friction lives in how existing tools are wired together and in defaults nobody chose deliberately. Adding a new tool on top of that adds another thing to learn and usually another place for configuration to drift.
The same numbers, measured again. Setup time, build time, review latency, time to first commit for the next joiner. If none of them moved, it did not work, and that is a more useful answer than a survey saying people are happier.
A survey and a measurement pass up front, then the fixes themselves, most of which are small. The largest single item is usually build time, and that one repays continuously — a fifteen-minute build costs about an hour a day per engineer once context switching is counted.

Sources

Page reviewed