Every enterprise I have worked in had golden rules.
Use this pipeline. Deploy this way. Don’t touch production on Friday. File a ticket for an environment. Put your Terraform in that repo, unless you are Team B, in which case ask Dave.
Some of those rules were wise. Almost none of them were walkable.
The difference matters. A rule is a sentence. A path is a sequence an engineer can complete on a Tuesday without a meeting, a waiver, or a folk hero.
I have come to believe that most “standards problems” are path problems wearing a compliance badge.
Why rules fail
Rules fail for the same reason unread runbooks fail. They ask humans to remember a procedure that the system could have made obvious.
When the official way is slower, vaguer, or slightly more humiliating than the unofficial way, people take the unofficial way. They are not rebels. They are adults with a deadline.
I do not blame them. I blame the product.
A golden path has three properties a golden rule never will:
- It is faster than the workaround. If it is not, you do not have a path. You have a suggestion.
- It is complete. Clone, build, test, preview, deploy, observe, roll back. Missing verbs become Slack threads.
- It fails out loud. A red check that says what broke and what to do is a teacher. A red check that says
Error: process completed with exit code 1is a dare.
If your “standard” lacks those three, stop calling it a standard. Call it a wish.
CI/CD is the first path
Pipelines are the most honest interface your platform has. They run on every change. They do not care about your slide deck.
A pipeline engineers trust is short enough to stay in flow, strict enough to catch the class of bugs you actually ship, and observable enough that a failure is a diagnosis, not a mystery.
A pipeline engineers do not trust becomes ritual. They re-run it. They skip it locally. They merge anyway because “it flakes.” The path is still there. The product is dead.
When I talk about modernizing GitHub workflows, I do not mean prettier YAML. I mean:
- One paved shape for the common case — lint, test, build, scan, deploy-to-preview — with extension points, not twelve snowflake workflows that drifted from a gist in 2021.
- Caching and concurrency that respect attention. A twenty-minute wait for a unit test job is not rigor. It is a tax.
- Signals that mean something. A required check should prove a claim. If it does not, delete it. Required theater trains people to ignore red.
Release engineering is Developer Experience. Anyone who has waited on a stuck deploy at 4:55 p.m. already knows this.
Self-service is the second path
Ticket-driven infrastructure is a golden rule pretending to be a process.
Need an environment? File a request. Wait. Context-switch. Come back to a namespace that is almost right. File another request.
Ephemeral environments and self-service infrastructure exist to collapse that loop. Not because tickets are morally wrong — because waiting is how you lose the problem you were holding in your head.
The implementation is unglamorous and specific:
- Terraform modules that encode the company’s actual constraints — networking, identity, tagging, secrets — so the default is compliant.
- Kubernetes and Docker as the runtime contract, not as a scavenger hunt through three clouds’ consoles.
- Preview environments that look enough like production to teach you something, and die when the pull request dies.
If standing up an environment requires a human in the loop for the common case, you have not built a platform. You have built a concierge.
Concierges do not scale. Paths do.
Cloud as a foundation, not a catalog
Azure, AWS, GCP. Kubernetes. Terraform. Docker. The list is not the strategy.
The strategy is: wrap the choice so a product team does not have to become a cloud anthropologist to ship a service.
Multi-cloud without a path is just three ways to be lost. Multi-cloud with a path is a set of primitives — identity, network, deploy, observe — that look the same from the engineer’s chair even when the substrate does not.
I care less about which logo is on the invoice than whether the paved road still works when the invoice changes.
Observability belongs on the path
A path you cannot see is a rumor.
Pipeline traces. Deploy markers. Environment inventory. The same discipline we demanded of production services — structured logs, ownership, SLOs — belongs on the developer platform itself.
If you cannot answer “how many preview environments are alive, who owns them, and what did the last deploy do?” you will eventually answer it during an incident, which is the most expensive time to learn.
The Expert Vision version
Experts do not start with your policy wiki. They look for structure. Where is the contract? Where is the rollback? Where is the example that is not a lie?
Give them that structure as a path — a repo template, a workflow, a module, a preview URL — and they will extend it. Give them a rule and a shrug, and they will invent a local dialect. Then you will spend the next year writing more rules to suppress the dialect.
I would rather spend the year making the official path unbeatable.
A practical test
Pick a service your organization ships every week. Ask a strong engineer who does not work on the platform team to:
- Create a preview environment.
- Run the full CI path.
- Deploy to a non-production target.
- Find the logs and the rollback.
Time it. Count the questions they have to ask a human.
That number is the distance between your golden rules and your golden path.
Shorten it. Then shorten it again. The rules can stay in the wiki if they want. The path is what people will actually walk.