A repo strategy decides where your code lives. A golden path decides how fast your team can ship it.
A few days ago I wrote about monorepo vs polyrepo, and one line in that article kept coming back to me:
"The repository structure isn't necessarily the problem. Lack of platform engineering is."
This article is that sentence, expanded.
Because here's a pattern I keep seeing: a team spends weeks in architecture meetings debating repo boundaries, naming conventions, ownership models — and then a brand-new service still takes three weeks to reach production. Not because the code was hard. Because setting up CI, security scanning, secrets, logging, and a deployment pipeline from scratch was hard.
The repo was never the bottleneck. The paved road was missing.
1. The Question We Keep Asking Wrong
Most platform conversations start with:
"Should this be a shared library, a shared repo, a shared pipeline?"
The more useful question is:
"When an engineer wants to build and ship something new, what is the fastest, safest way for them to do it — without reinventing infrastructure every time?"
That question has a name: a golden path.
2. What a Golden Path Actually Is
A golden path (sometimes called a "paved road") is the opinionated, well-supported, default way of doing something inside an engineering organisation.
New service needed
↓
Golden path exists?
↓
Yes ──────────────► Use the template
CI/CD pre-wired
Security scans included
Observability included
Deploy in hours
No ───────────────► Build pipeline from scratch
Negotiate access
Copy-paste from another team
Deploy in weeks
It's not a mandate. It's not the only way. It's the way that requires the least thought, because the platform team has already made the hard decisions for you — and tested them.
3. A Familiar Scenario
Imagine two engineers, same company, same week, both asked to ship a new internal service.
Engineer A (no golden path):
- Copies a Dockerfile from a service that "looked similar"
- Manually requests CI runners
- Asks three people how secrets are supposed to be managed
- Finds out the logging format is inconsistent with the rest of the org
- Ships in week 3, with gaps the security team finds a month later
Engineer B (golden path exists):
- Runs
platform create-service - Gets a repo with CI, linting, test scaffolding, a Dockerfile, and a deployment manifest already wired to the org's standards
- Observability and secrets are configured by default
- Ships by day 2
Same company. Same skill level. Different experience entirely — because of infrastructure, not ability.
This is the gap platform engineering exists to close.
4. Why "Just Pick Monorepo or Polyrepo" Doesn't Fix This
A monorepo makes code visible. A polyrepo makes ownership explicit. Neither one, by itself, gives you:
- a pre-approved way to stand up a new service
- consistent security scanning
- consistent CI/CD behaviour
- a known, supported way to deploy
You can have a perfectly organised monorepo and still have every team building CI pipelines from scratch inside it. You can have 80 polyrepos and still have them all following the exact same paved road, because a platform team maintains the template they were all created from.
Repo strategy is about where code lives.
Platform engineering is about how code gets from an engineer's laptop to production, safely, repeatedly, and without reinventing the wheel every time.
5. What This Looks Like in Practice
This isn't a new idea — several engineering orgs have publicly written about building exactly this kind of paved road:
- Spotify popularised the term "golden path" itself, and open-sourced Backstage as a developer portal so engineers could discover services, templates, and documentation in one place instead of hunting through wikis.
- Netflix has talked publicly about its "paved road" philosophy — teams are free to go off-road, but the paved road is deliberately the path of least resistance, kept effortless on purpose.
- Uber and several other large engineering orgs built internal developer portals specifically because the cost of onboarding a new microservice had quietly become one of their biggest sources of engineering time loss.
The common thread isn't the tooling. It's the philosophy: make the right way the easy way.
6. The Anatomy of a Golden Path
A good golden path usually bundles together:
Golden Path
│
├── Service template (language, folder structure, linting)
├── CI pipeline (build, test, security scan — pre-wired)
├── Deployment manifest (Kubernetes/Terraform defaults)
├── Observability (logging, metrics, tracing — on by default)
├── Secrets & access management (no manual requests)
└── Documentation (how it works, how to deviate)
Notice the last item: how to deviate. A golden path that has no escape hatch isn't a golden path — it's a mandate wearing a nicer name. More on that below.
7. Golden Path vs Guardrail vs Mandate
These three get confused constantly, so it's worth separating them:
| Concept | What it means | Example |
|---|---|---|
| Golden path | The easiest default. Optional but heavily incentivised. | A pre-built service template with CI/CD included |
| Guardrail | An automated check that prevents unsafe behaviour. | A pipeline that blocks deploys without passing security scans |
| Mandate | A rule enforced regardless of context. | "All services must be written in Go" |
Healthy platform engineering leans on golden paths and guardrails. Mandates, used too liberally, create resentment and workarounds — engineers will always find a way around a rule they don't believe in.
8. The Hidden Cost of Not Having a Golden Path
When there's no paved road, every team quietly builds their own:
Team A → Jenkins, custom Dockerfile, manual secrets
Team B → GitHub Actions, different base image, different logging format
Team C → GitLab CI, yet another deployment pattern
Nobody did anything wrong. Each team solved their own problem reasonably. But now:
- Security has to audit N different pipelines instead of one
- Incident response is slower because every service logs differently
- Onboarding a new engineer means re-learning infrastructure per team
- Upgrading a shared dependency (say, a security patch) means N different manual rollouts
This is the same "hidden coupling" problem from the repo-strategy article — just moved from code to infrastructure.
9. Treat the Platform Like a Product
The single biggest mindset shift that makes platform engineering work: the platform team's users are other engineers, and the platform is a product they chose to use — not a policy they're forced to follow.
That means:
- Golden paths should be genuinely easier than the alternative, not just officially sanctioned
- Platform teams should gather feedback like a product team does — adoption metrics, friction points, feature requests
- Deviating from the golden path should be possible, just slightly more effort — never blocked outright without a very good reason
If engineers are opting out of the golden path en masse, that's not a compliance problem. That's a product-market-fit problem.
10. A Practical Decision Framework
Instead of asking "do we need a platform team," ask:
| Question | Signal |
|---|---|
| Are multiple teams solving the same infra problem independently? | Build a golden path |
| Does onboarding a new service take days instead of hours? | Build a golden path |
| Are security/compliance checks inconsistent across services? | Add guardrails |
| Is the platform team becoming a bottleneck for every deploy? | Loosen the mandate, strengthen self-service |
| Are engineers bypassing the golden path regularly? | Treat it as product feedback, not a discipline issue |
| Is the org under ~20 engineers? | A lightweight template may beat a full platform team |
Platform engineering, like repo strategy, is a set of trade-offs — not a universal answer.
11. What I'd Avoid
Anti-pattern 1: Building the platform before anyone asks for it
Platform teams that build in isolation from product teams tend to build the wrong thing, beautifully.
Anti-pattern 2: No escape hatch
If the golden path is the only path, it becomes a bottleneck the moment it doesn't fit an edge case — and it always eventually doesn't.
Anti-pattern 3: Treating the platform as "done"
A golden path that isn't updated as the org's needs evolve becomes the exact legacy problem it was built to prevent.
Anti-pattern 4: Measuring success by mandate compliance
"90% of services use our template" is a vanity metric if engineers are using it because they have to, not because it's genuinely the fastest option.
12. How to Start, Practically
If there's no golden path today, you don't need a platform team of twenty to begin:
- Pick the single most repeated piece of setup pain (usually CI/CD scaffolding or service bootstrapping)
- Build one opinionated template for it
- Use it yourself on the next real service — don't theorise it
- Get one other team to adopt it and listen hard to their friction
- Only then formalise it into a platform with documentation and ownership
Golden paths earn trust by being used, not by being announced.
13. The Takeaways
- Repo strategy and platform engineering solve different problems. One is about code organisation, the other is about developer experience.
- A golden path is the easiest default, not a mandate. It should be fast enough that engineers want to use it.
- Guardrails, not rules, keep things safe at scale. Automate the check, don't just write the policy.
- The platform is a product. Its users can, and will, opt out if it isn't good.
- Start small. One good template beats a grand, unused platform roadmap.
Final Thought
The monorepo vs polyrepo debate gets attention because it's visible — you can see it in the folder structure. Platform engineering is invisible when it's working, which is exactly why it's underinvested.
But ask any engineer who has shipped a service in three hours on a well-paved road, and then shipped one in three weeks without it — they'll tell you which decision actually mattered more.
Choose your repo strategy deliberately. But build the road before you argue about where it should lead.
This is the second article in a series on engineering decisions that look architectural but are really about people and workflow. First one was on monorepo vs polyrepo — next one's on single-agent vs multi-agent systems, and it turns out the same boundary questions show up there too.
Top comments (0)