Platform engineering is the name the industry settled on for a correction many of us made out of necessity: you-build-it-you-run-it DevOps collapses at organizational scale, because every product team cannot realistically master Kubernetes, Terraform, cloud IAM, and an observability stack on top of actually shipping features. The answer is an internal developer platform — a curated set of self-service capabilities that absorbs that undifferentiated toil so product teams can spend their cognitive budget on the product.
The failure mode is equally well known by now. Platforms built as mandates get routed around: shadow infrastructure blooms in team-owned cloud accounts, and two years later the platform team is maintaining a system nobody would choose. The difference between the two outcomes is rarely technical. It is whether the platform is run as a product with users or as a control point with hostages.
Treat the Platform as a Product
A platform team needs a product management function, even part-time: user interviews with development teams, a public roadmap, and adoption metrics reviewed the way a startup reviews revenue. Your users can churn — not to a competitor, but to a hand-rolled Jenkins box and a personal cloud account, which is strictly worse for everyone. Track adoption per capability, time-to-first-deploy for a new service, and the number of infrastructure requests that still require a human. When a golden path is not being chosen even though teams have a real alternative, that is product feedback to act on, not a compliance gap to escalate.
Golden Paths, Not Golden Cages
A golden path is the supported, templated route from idea to production. The critical property — this is Spotify's original framing — is that it is optional but overwhelmingly convenient, with explicit escape hatches. Teams can step off the path, but they visibly inherit the operational burden they leave behind. The path itself is a bundle of concrete assets:
- ▸Scaffolding: Backstage software templates or a plain cookiecutter that generates the repository, CI pipeline, deployment manifests, and dashboard wiring in one shot.
- ▸Paved CI/CD: shared, versioned pipeline definitions — reusable GitHub Actions workflows or GitLab CI includes — so SBOM generation, image signing, and vulnerability scanning are defaults rather than per-team homework.
- ▸Self-service infrastructure: Crossplane compositions or well-reviewed Terraform modules behind a catalog, so a Postgres instance is a claim in a manifest instead of a ticket in a queue.
- ▸Production-readiness scorecards: ownership, SLOs, runbooks, and alert routing scored automatically in the catalog, replacing readiness review meetings with a checklist everyone can see.
Start with the Thinnest Viable Platform
The most common implementation mistake is starting with a portal. Backstage is a framework, not a product; without dedicated frontend investment it becomes an expensive, stale catalog that erodes trust in the whole initiative. The Team Topologies notion of the thinnest viable platform is the better compass: build the smallest thing that reduces cognitive load for real teams this quarter. Sometimes that is a documented template repository and a Slack channel with a fast response time. Portals — Backstage, Port, Cortex — earn their place once there are enough golden paths that discovering them is the bottleneck, and not before.
A 90-Day Starting Plan
1. Interview five product teams and write down their top three frictions between commit and production. Build nothing yet. 2. Pick the single worst friction and pave that path end to end with one pilot team as a design partner. 3. Measure lead time and ticket volume before and after; publish the numbers internally, including what failed. 4. Extract the template, document the escape-hatch policy, and onboard two more teams by invitation rather than mandate. 5. Re-run the interviews and pick the next friction. Evaluate a portal only when discovery of existing paths is what slows teams down.
The business case shows up in numbers leadership already tracks. DORA metrics move when environments and pipelines stop being bespoke; onboarding time for new engineers drops when there is one obvious way to ship; and security posture improves because controls live inside the paved road instead of inside policy documents nobody reads under deadline. There is a quieter benefit for companies competing for senior engineers: nobody stays long at a place where deploying a service takes three weeks and four tickets. A platform that developers choose freely is a retention tool as much as an efficiency one, and it compounds — every team that joins the path makes the next migration, audit, and incident cheaper.