What is a "golden path" (paved road) in technical strategy, and how do you get adoption without turning it into a mandate?
answer
- template + pipeline + observability + security, pre-wired
- make the right way the easy way
- escape hatch exists, but you carry the pager
- platform as product: users, roadmap, migrations
- measure adoption, time-to-first-deploy, abandonment
basics
~20 sA golden path is a supported, opinionated default way to build and run a service — templates, libraries, pipeline, logging, deployment — so teams get the common work for free. You drive adoption by making it the easiest option, not by forbidding alternatives.
solid answer
~50 sA golden path (or paved road) is the pre-integrated, supported route from idea to production for the most common case: a project template, the standard build and CI/CD pipeline, baked-in observability, security defaults, secret management, deployment and on-call wiring, plus documentation. It exists to remove undifferentiated decisions from every team and to make the secure, observable, compliant choice also the fastest choice. Adoption follows from developer experience: it must be genuinely faster than rolling your own, kept current, and supported by a real team treating it as a product with users, feedback and a roadmap. Keep escape hatches — teams can leave the path, but then they own the operational and compliance burden themselves, and that choice is recorded. Measure it: adoption rate, time from repo creation to production, and how many teams abandon it. If teams route around it, the path is the problem, not the teams.
go deeper
Describe it as the ready-made, supported starting point — template, pipeline, logging, deployment — so teams do not reinvent the basics.
Add that it makes the secure and observable choice the fastest choice, and that it is a default, not a rule, with an escape hatch.
Cover platform-as-product mechanics: ownership, versioning, migrations, support model, adoption and abandonment metrics, and the small set of genuine non-negotiables.
Frame it as how strategy becomes default behaviour at scale: funding model, relationship to the radar and north-star, compliance by construction, and using off-path demand as the platform roadmap signal.
### What a golden path is A **golden path** (Spotify's term; Netflix's "paved road" is the same idea) is an opinionated, supported, end-to-end route through the toolchain for the most common kind of work. For a backend service it typically includes: - A **project template / scaffolding command** that generates a runnable service with the org's conventions. - The **standard CI/CD pipeline**: build, test, static analysis, artifact signing, deployment stages. - **Observability by default**: structured logging, metrics, distributed tracing, a starter dashboard and alerts already wired. - **Security defaults**: authentication/authorisation integration, secret management, centrally patched base images, dependency scanning. - **Runtime wiring**: deployment manifests, autoscaling, health checks, on-call/paging registration, service catalogue entry. - **Documentation and a support channel**. The economic logic: decisions that are the same for every team are made once, well, by people who specialise in them, and are then handed out for free. Teams spend their scarce attention on the domain problem, which is the only part that differentiates the business. ### Why it belongs to technical strategy A north-star architecture and a technology radar express *intent*. A golden path is the **mechanism** that makes intent the default behaviour. The Adopt ring becomes real when Adopt choices are already wired into the template. Compliance and security requirements stop being checklists reviewed after the fact and become properties you get by construction — often called *compliance by default* or "secure by default". ### Paved road, not mandate The crucial distinction: - A **mandate** says "you must use X". It creates resentment, exception queues, and shadow systems, and it makes the platform team's failures everyone's problem with no feedback loop. - A **paved road** says "X is supported; here is everything you get for free. You may drive off-road, but then you carry the support, security patching, on-call tooling and audit burden yourself." The off-road option must be real but honestly priced. This preserves the ability to innovate (today's off-road experiment is next year's paved road) while making the default overwhelmingly attractive. Some organisations do add a genuine mandate for a narrow set of non-negotiables — for example, all production traffic must go through the standard identity layer, or all data at rest must use approved encryption — and pave everything else. Keeping the mandated set small is what keeps it credible. ### Treat the platform as a product - **Users**: internal engineers. Do user research, watch onboarding, count friction. - **Roadmap and versioning**: templates rot; a golden path with a two-year-old framework version is a trap that teams inherit. - **Migration support**: when the path changes, the platform team provides automated codemods or migration tooling instead of filing tickets against every team. - **Support model**: a channel, an SLA, and office hours. Unsupported paths are not paths. ### Metrics that tell you if it works - **Adoption**: share of new services created from the template; share of production traffic on the path. - **Time-to-first-deploy** for a new service (hours vs. weeks). - **Drift**: how many services fall behind the current template version. - **Abandonment**: teams that started on the path and left — the strongest signal of defects. - Downstream, the DORA delivery metrics (deployment frequency, lead time, change failure rate, time to restore) for on-path vs. off-path services. ### Failure modes - **Gilded cage**: so rigid that any non-standard need forces a full escape, so teams leave wholesale. - **Abandoned road**: built during a platform initiative, then unstaffed; teams are stuck on a frozen template. - **Golden path as gate**: turning it into a mandatory review board reintroduces the queue it was meant to remove. - **Paving the wrong road**: automating a workflow nobody has, because the platform team never talked to delivery teams. - **Too many paths**: five templates that each cover a third of the need.
- A team insists their workload does not fit the golden path. What do you do?Let them off the path, make the extra burden explicit (they own operations, patching, observability, compliance evidence), record the deviation with a review date, and treat the mismatch as input to the platform roadmap — repeated mismatches mean the path needs widening or a second path is justified.
- How do you keep a golden path from going stale?Staff it as a product with an owner and roadmap, version the template, publish drift metrics per service, ship automated migrations rather than tickets when the path changes, and make the path's own upgrades part of the platform team's delivery commitments.
A paved road versus off-road driving: nobody forbids the dirt track, but the road is faster, lit, patrolled and maintained. Most drivers choose it freely — and the few who go off-road bring their own recovery gear.
saying these in an interview costs you the question
- Enforcing the golden path as a mandate with no escape hatch
- Building a path from central assumptions without talking to delivery teams
- Shipping a template once and leaving it unowned and unversioned
- Measuring success by the number of paved features rather than adoption and time-to-first-deploy
- Adding a review board on top of the path, recreating the queue it was meant to eliminate
- Claiming the golden path removes the need for any team-level operational ownership