Golden Paths: Make the Platform the Easy Way, Not the Mandate¶
A new service went from an empty repo to running in staging in twenty minutes. Scaffold, CI wired in, monitoring attached, deployed. The team next door filed an onboarding ticket for a new service that same morning and got a response three weeks later.
Both teams work at the same company, on the same platform. One found the golden path. The other found the ticket queue. And here's the part that should worry you if you run a platform team: the second team isn't going to file that ticket again next time. They're going to copy an old repo and hand-wire the parts themselves, because that's faster than waiting three weeks, even if it means drifting further from every standard you've built.
The signal that actually matters
Adoption numbers tell you who tried the platform. They don't tell you who's still using it. The real signal is quieter: teams that gave up on the platform don't complain, they just stop filing tickets and start building their own thing next to it. Silence is the metric to watch, not satisfaction scores.
Why "use the platform" as a policy doesn't work¶
Mandates create compliance theater. A team technically uses the platform because they were told to, but the moment it's inconvenient, they route around it. Nobody announces this. It just shows up months later as a Terraform pipeline sitting next to the mandated Crossplane one, built by a team that got tired of a three-week onboarding queue and quietly solved their own problem.
This is what we saw across the platform talks at KubeCon EU this year: the teams getting real adoption weren't the ones with the strictest mandate, they were the ones whose platform was legitimately the fastest way to get something done. Shadow infrastructure isn't a discipline problem. It's a symptom that tells you exactly where your platform is slower than the alternative.
The silence tell
If ticket volume for platform onboarding has been flat for a quarter, that's not necessarily good news. Check whether teams stopped needing help, or whether they stopped asking and started building around you instead.
What a golden path actually is¶
A golden path is the fastest way to do the right thing. It is not the only way to do anything, and it's not a template repo that gets forked once and drifts out of date within a month. The difference matters: a mandate says "you must," a golden path says "this is easier," and only one of those survives contact with a deadline.
If your golden path isn't measurably faster than a team hand-rolling it themselves, it's just a suggestion with extra steps. That's the bar: it has to win on speed against the DIY alternative, every time, or teams stop taking it.
Building a golden path with Backstage and ArgoCD¶
The mechanics that make this real: a Backstage software template scaffolds a new service with CI, monitoring, and an ArgoCD Application manifest already wired in. The template hands off to an ArgoCD ApplicationSet generator, so the new service registers itself in GitOps without a platform engineer touching a config file by hand. This builds directly on the self-service ArgoCD catalog pattern — the template is the front door, the ApplicationSet generator is what makes the back end actually self-service instead of self-service in name only.
# Illustrative ArgoCD ApplicationSet generator —
# picks up new services registered via the Backstage
# template without a platform engineer touching config
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: golden-path-services
spec:
generators:
- git:
repoURL: https://github.com/org/service-catalog.git
revision: main
directories:
- path: services/*
template:
metadata:
name: '{{path.basename}}'
spec:
project: default
source:
repoURL: https://github.com/org/service-catalog.git
targetRevision: main
path: '{{path}}'
destination:
server: https://kubernetes.default.svc
namespace: '{{path.basename}}'
Twenty minutes is the number to protect
That's not a marketing figure, it's the actual time from "empty repo" to "running in staging" once the template and the ApplicationSet generator are wired together correctly. If a change to either one pushes that number up, treat it as a regression, the same way you'd treat a latency regression in production.
Measuring whether the golden path is actually working¶
Adoption rate on its own doesn't tell you enough. Track time-to-first-deploy for a new service, and track how often teams fork the template and never update it again, which is a proxy for the path no longer being fast enough to keep up with. Tie both of those back to the outcome metrics that actually matter: lead time and change failure rate, pulled automatically from GitHub and PagerDuty rather than estimated from memory in a monthly status update.
| Indicator | What it tells you |
|---|---|
| Time-to-first-deploy | Leading signal — is the path still fast? |
| Template fork-and-abandon rate | Leading signal — are teams drifting away? |
| Lead time, change failure rate | Lagging signal — is the outcome actually better? |
Scorecards make this visible
If you're already running monthly platform scorecards, golden path adoption metrics belong in that report, not in a separate deck nobody reads. The whole point of a scorecard is that "the platform is working" stops being a claim and starts being a number someone can check.
Where golden paths break down¶
A golden path that isn't maintained becomes a trap. The teams that adopted it early get stuck on an outdated pattern while the platform team's attention has already moved to the next thing. Ownership has to include a deprecation and upgrade path from the start, not just a launch announcement — otherwise "golden path" quietly becomes "legacy pattern nobody wants to touch" within a year.
FAQ¶
What's the difference between a golden path and a golden template?
A template is a static starting point that drifts the moment it's forked. A golden path is the whole loop: the template, the automation that wires it into your platform, and the ongoing maintenance that keeps it faster than the alternative. A template without the maintenance loop degrades into exactly the shadow-infrastructure problem golden paths are supposed to fix.
Do golden paths work without Backstage?
Yes. Backstage is a common implementation choice because of its software template and catalog features, but the underlying pattern, scaffold plus automatic GitOps registration, works with any internal developer portal or even a well-built CLI, as long as it's genuinely faster than doing it by hand.
How do you measure golden path adoption?
Track time-to-first-deploy as your leading indicator, and watch fork-and-abandon rate on the template itself. Tie both to lead time and change failure rate as the lagging outcome metrics that tell you whether adoption is actually translating into better delivery.
What happens when a team needs to deviate from the golden path?
A good golden path has an explicit, fast exception process, not a silent workaround. If deviation requires a three-week approval cycle, teams will route around you the same way they route around a mandate — you've just rebuilt the ticket queue with extra steps.
Twenty minutes versus three weeks isn't a rounding error, it's the whole difference between a platform people choose and one they tolerate. Build the path fast enough, and you stop needing to mandate anything at all.