Platform teams tend to describe the golden path as a recommendation. Product teams experience it as a bet: if I use this, will it get me to production faster than doing it myself?
They re-evaluate that bet on every project, and they are ruthless about it. Which means a golden path is not a policy you announce. It is a claim you have to keep winning.
The bypass is rational, almost always
When a team routes around the platform, the instinct is to read it as a discipline problem and reach for enforcement. In our experience that reading is wrong far more often than it is right. The usual causes are mundane:
- The path does not support something the team genuinely needs, such as an unusual datastore or a legacy protocol.
- It supports it, but the team could not find out how, and asking cost them a day.
- It works, but it is slower than the thing they already have in a repository from last year.
- It works, but when it broke nobody could tell them why, and they are not willing to be blocked again.
Every one of those is a defect in the platform. None of them are fixed by telling people to use the platform.
Blocking the escape hatch makes it worse
The tempting response is to remove direct access so the golden path is the only path. This produces one of two outcomes, and both are bad.
Either delivery stops while teams wait for the platform to grow the capability they needed, and the platform team becomes the bottleneck it was created to remove. Or people find a route you did not anticipate, which is now invisible to you as well as unsupported.
An escape hatch you can see is safer than one you have driven underground.
Keep the hatch, but instrument it. Knowing which teams are going around and what they reached for is the most valuable roadmap input a platform team gets.
Treat every bypass as a bug report
The rule that served us best: when someone routes around the platform, that is a bug report about the platform. Not an escalation, not a compliance finding. A bug report, triaged like any other.
This changes the conversation completely. Instead of a platform team defending its adoption numbers and a product team defending its deadline, you get a specific missing capability with a named requester. Some of those you will fix. Some you will decline, deliberately, and document why. Both are fine. What is not fine is not knowing.
Make the gap visible before it becomes a fork
The expensive version of this problem is not one team going around once. It is a second, informal platform accreting inside the organisation, usually as a shared repository of copied configuration that three teams now depend on.
By the time that exists it has its own users and its own inertia, and consolidating means asking teams to migrate away from something that currently works for them. Catching the first bypass is dramatically cheaper than untangling the fourth.
What good looks like
A healthy platform has bypasses. A platform with none is either very young or is being enforced rather than chosen, and enforcement conceals the signal you most need.
What you want is a small, known set of exceptions, each with a reason someone can articulate, and a trend where new services default to the path without anyone having to be persuaded. That is adoption. Everything else is compliance wearing its clothes.
