Path Exit Rate

A platform team reports 30% adoption of its golden path and asks for headcount to improve the experience. The number that would have told them what to build is different: of the 42 teams that did not finish, 31 stopped at the same step — the one that hands you a ticket for a database.

Adoption is an outcome. Exit rate is a cause. An adoption percentage aggregates every reason a team left into one figure, so a platform can spend a year improving the parts of the path people already liked while the step that pushes everyone off stays untouched. Counting exits per step points at one thing to fix and gives a measurable prediction about what fixing it will do.

The reason this matters more on a paved road than on a normal product funnel is that the steps are serial and the alternative is always available. A team that has to leave the path at step nine has, by then, written its own deployment configuration and filed two tickets. It does not come back for steps one to eight next time. One uncovered step does not cost you a fraction of the value; it costs you the journey.

Why it matters

A path covering eight of eleven steps sounds like 73% of the value and delivers closer to none, because the three uncovered steps are on the critical path to a service that serves traffic. In a typical estate those are a database, a DNS record and an on-call rota, and the tickets behind them take four to nine days against a generator that takes ten minutes. The platform's visible surface is fast and the invisible remainder sets the elapsed time, which is why teams describe a path as slow that the platform measures as instant.

Exit rate also converts arguments into evidence. "Teams do not follow the standard" and "the standard stops halfway" are indistinguishable in an adoption number and obvious in an exit distribution.

Implementation patterns

• Emit an event per step, not per completion. Journey identifier, step name, outcome, elapsed time. Without the journey identifier you can count completions and never attribute an abandonment.
• Count the journeys that never started in your tooling. Services appearing in the registry with no journey record are exits at step zero, and they are usually the largest bucket in the first month of measuring.
• Instrument the ticket queues as steps. If the path hands off to a ticket, that hand-off is a step with a latency and an exit rate. Excluding it is how a platform measures itself as fast.
• Publish the distribution monthly, per step, with the elapsed time at each step. Two columns: where journeys stop, and how long the ones that continue waited.
• Sample exits qualitatively. Five short conversations per month with teams that left tell you whether the step was missing, wrong, or simply slower than doing it by hand.

Industry example

The public engineering record on internal platforms is thin on numbers because the data is embarrassing, so the honest version is an archetype drawn from what the practice literature has described since Team Topologies put cognitive load on the agenda in 2019: a platform group at a mid-size company published 30% golden-path adoption for a year and treated it as a marketing problem, running internal campaigns and a documentation rewrite. When they finally instrumented steps in production, a third of journeys stopped at the database request and another quarter at network policy approval — neither of which the platform owned. Extending the path across those two steps moved adoption further in a quarter than the previous year of persuasion. The mechanism is the same everywhere: the earliest uncovered step dominates, and it is almost never the step a platform team enjoys working on.

Failure scenarios

• Aggregate-only reporting. A single adoption figure hides the fact that all exits are at one step, and the roadmap becomes whatever the team already wanted to build.
• Instrumenting only the portal. Exits recorded up to the hand-off and nothing after produce a path that looks 100% successful while nothing reaches production.
• Optimising the widest step instead of the earliest. Later steps are only reached by survivors, so their raw counts look small; they are not small as a proportion of who got there.
• Using exit rate as a stick. Publishing per-team exits invites teams to stop using the tooling at all, which destroys the measurement and the trust in one move.

Trade-offs

The real cost is political rather than technical. Exit rate makes visible that the path stops at a boundary owned by the network team or the DBAs, which turns a platform metric into a cross-team negotiation. That is the point, and it is uncomfortable.

When not to use it

Below roughly ten journeys a month the distribution is noise: talk to all six teams instead, which is faster and more informative than a funnel with single-digit buckets. Do not instrument a path that is still changing weekly — you will measure the scaffolding. And if the path is genuinely mandatory with no alternative, exit rate collapses to a queue-length measure and completion latency per step is the more useful signal.

Interview question

Q: Your internal platform reports 35% golden-path adoption and leadership wants it at 80% within two quarters. What would you measure first, and what would you refuse to do?

What a strong answer covers: measuring exits per step before promising anything; naming the likely early exits (provisioning hand-offs, approvals, anything that becomes a ticket); refusing a mandate, because it converts a coverage problem into a compliance problem and destroys the only honest signal of usefulness; committing to a coverage change rather than an adoption target; and stating the prediction — if the database step is 30% of exits, covering it should move adoption by roughly that much, and if it does not, the model was wrong and you now know something.

Quick check

Quiz: A path covers 8 of 11 steps and adoption is 30%. Why is extending coverage a better investment than improving the covered steps? — Because the steps are serial and the earliest uncovered one sends every journey off the path regardless of how good the first eight are.

Flashcard: What does path exit rate measure that adoption percentage cannot? — Where teams are forced off the supported path, step by step, which is the one thing that tells you what to build next.