What needs to be finished first
A platform or enabling team exists with a mandate to set standards and provide tooling for other teams.
Architecture decisions for the components recommended in the Golden Path are documented as ADRs.
What needs to be ready before start
Repository or wiki area for Golden Path docs; diagram tool (Mermaid, Excalidraw, Lucidchart); a sample repository as template anchor; list of links to tooling (CI templates, IaC modules, service libraries); list of existing paths used by each team.
Platform team as Golden Path owner; one technical writer or senior engineer as primary author; representatives from two to three product teams as reviewers; one architect or principal engineer as approver.
Precisely scoped use case (for example "new backend service with public API"); existing best-practice examples from two to three teams; known pain points the path should solve; non-negotiable compliance and security requirements.
1-3 days for initial setup, ongoing maintenance
Create doc structure with overview, prerequisites, step-by-step, templates, standards/checks, exceptions, FAQ. Link sample repository. Show owner and Slack channel for questions.
The one question this method answers
Which path takes a team from zero to a production-ready state for the defined use case in under one day without breaking standards?
Marker: Sektion
| Step | Duration | Action | Hint |
|---|---|---|---|
1Section 1: Sharpen use case | 30-60 min | Define the use case in one sentence: what is the target outcome of the path (for example REST backend in Go with Postgres and central SSO authentication). Explicitly list what is out of scope. | If the use case is too broad ("any service"), the Golden Path becomes generic documentation. Better define three narrow paths than one for everything. |
2Section 2: Describe the path | 2-6 h | Build a step-by-step guide from repository setup to production deployment. Include one concrete command, template link, or click path per step. Estimate time per step. | If steps exceed one paragraph, automation is missing. Templates and scripts should replace narrative text. A path should stay below twelve steps. |
3Section 3: Templates and automation | 4-16 h | Link or create existing templates (Cookiecutter, GitHub templates, Terraform modules). Evaluate Backstage software templates or similar tooling. Provide CI pipeline templates. | Documentation without templates becomes stale quickly. Teams that only copy commands and config from a wiki page lose consistency within four weeks. |
4Section 4: Standards and checks | 1-2 h | Document mandatory quality and security checks: linting, tests, SAST, SBOM, logging conventions. Specify which checks are automated (CI) and which are manual. Define acceptance criteria for being "on the path." | If mandatory checks exist only as plain text, they will be bypassed. Automation in CI is required for all security and compliance-relevant points. |
5Section 5: Exceptions and FAQ | 1-2 h | Section "if your use case deviates": when is deviation legitimate, how should it be documented (ADR), and who decides. Add common questions from pilot teams to FAQ. | Without an opt-out path, Golden Path feels authoritarian and is bypassed informally. A visible exception process lowers resistance and reveals drift. |
6Section 6: Pilot and adoption | 2-4 weeks | Run path with one to two pilot teams. Observe where friction appears and improve documentation iteratively. Communicate publicly only after successful pilot. | Publishing without a pilot produces docs that fail at first use. Pilot team feedback must be incorporated into v1.0. |
What comes out at the end
Golden Path guide in wiki, Backstage, or repo with sections for overview, prerequisites, step-by-step commands, template links, standards/check list, exception process, FAQ and owner contact. Include template repositories or Backstage templates.
Use semantic versioning for the path (v1.0, v1.1, v2.0 for breaking changes). Place changelog at the top of the documentation. Keep deprecated paths linked with migration notes; do not silently replace them.
Compact working template for Golden Path with context, input, output artifacts, and next step.
Describes the recommended standard path that helps teams reach a common technical goal reliably.
When and for what do we use this method?
Which data, observations, decisions, or materials are available?
Short notes along the runsheet.
Owner, date, and success signal.
Concrete filled scenario, fictional example
Concrete filled scenario, fictional example
Owner: Platform team, Slack #platform-help.
Use case: REST backend in Go for internal or external traffic, persistent data in Postgres, authentication with central Okta SSO, deployment on Kubernetes (cluster prod-eu1).
Out of scope: Event-driven backends (see Golden Path Kafka service), frontend hosting, ML workloads.
Prerequisites: GitHub membership, Okta account, local tools (Go 1.22, Docker, kubectl, helm).
Steps
gh repo create --template platform/template-go-service (estimated 2 min).service.yaml (owner team, SLOs, data category).make dev. Postgres runs in Docker Compose. (~5 min).make auth-init creates Okta app via Terraform module okta-sso. (~10 min).staging automatically on merge to main.prod via make promote after manual approval. (~3 min).Standards (automated in CI)
go test, Coverage >= 70%), SAST (gosec), container scan (trivy), SBOM (syft).Exceptions: If your service needs a different database (for example Redis as primary), open an ADR in repo platform-adrs and a Slack thread in #platform-help. Platform team decides within 5 business days.
Pilot experience (team Discovery, May 2026): 4 hours to first deploy. Friction with Okta module due to low example coverage, fixed in v1.1.
Next version: v1.1 with expanded Okta docs and deadline 15.06.2026.
Recognize symptoms and steer against them
Path is documented as a 30-page wiki but has no templates or scripts; teams copy manually.
For each step, check whether a command or template exists. If not, create one before v1.0. Documentation-only paths usually become stale within 8 weeks.
Path feels mandatory without an exception process, teams bypass it informally.
Add an exception section with a clear ADR process and a visible decision location. Publish known exceptions as examples so the format is accepted.
"Golden Path for all services" makes documentation generic and use cases diverge too strongly.
Narrow the use case. Prefer three narrow paths (for example Go-REST, Kafka consumer, frontend SPA) over one broad path.
Path is published without real usage, and first team using it fails after step three.
Use one to two pilot teams before broad communication. Feed pilot frictions back into v1.0. No pilot, no v1.0.
Tooling versions (Go, Postgres, Terraform module) are outdated, causing incompatibilities in pilot teams.
Quarterly review is required. Add automated tests in template repo for tool updates. Ownership and escalation if owner is inactive.
Done signals checkable in under a minute
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.