By Matt Menzenski — 29 Nov 2025

When a Golden Path Becomes a Golden Cage

This post is part of the Content Club, organized by Bryan Ross. The theme for November 2025 is "Getting the balance right: golden paths versus golden cages". Links to other posts in this group are at the end of this post.

Platform Engineering is a field that deals in a tremendous amount of abstraction. Everything is "in the cloud", everything is "virtual": we have virtual machines that run in virtual private clouds and provide virtual environments. Unsurprisingly, platform engineering practitioners love metaphors that help explain the abstract concepts from their field in terms of the physical world and the built environment that surrounds them. We say that we're building paved roads to help developers move more efficiently. We talk about building guardrails to help product teams avoid falling off a cliff of complexity. We love to talk about providing golden paths that illuminate the way for our developers. It's that last metaphor (the golden path) that I'd like to dig into today, along with the contrasting image of the golden cage.

The metaphor of the golden path in platform engineering originates from the use of the term in Frank Herbert's Dune series of science-fiction novels (a blog post on platform engineering at Spotify makes this origin clear), where it represents the sole possible future in which humanity survives, compared to the many potential futures in which humanity does not. It is not the best option, but the least bad one - an optimization within severe constraints. Developers live within constraints too, although thankfully the stakes there are much lower.

In platform engineering practice, the term "golden path" refers to a sanctioned, streamlined way for teams to launch, operate, and maintain their workloads within a platform system. The goal is not to restrict what teams can do, but to standardize common use cases so that cognitive load is reduced for both the developers consuming platform resources and the platform teams maintaining them.

What a golden path looks like in practice varies dramatically by organization. In one setting, it might be a way to deploy a microservice to Kubernetes with logging, tracing, database, and authentication capabilities included by default. In another, it might be something else entirely. What matters is that a golden path helps teams deliver the differentiating business value they are responsible for in a sustainable and maintainable way.

A defining feature of a golden path is that it is optional. It is offered, not imposed. The goal is to provide so much value — and such a reduction in friction — that teams choose it willingly over the alternatives.

This optionality is embedded in the idea of a “path.” If you’re walking through the woods on a footpath and something catches your eye, you can step off the trail to pursue it. It may require clambering over rocks or pushing aside branches, but on foot that’s usually manageable. If it were a golden road, leaving it would be harder. There would be curbs, guardrails, sanctioned exit ramps, rules about where you can rejoin traffic. A road channels you. A path guides you.

And a path, critically, cannot be built - it can only emerge. It arises in collaboration between an environment and those who travel through it. The map is not the territory, but a path is the rare place where map and territory meet.^[1]

An ideal golden path, then, is optional in multiple ways. Teams can choose not to use it, and if they are using it, they can choose to leave it. When you cannot opt out, what you have is a golden cage.

If a golden path decreases cognitive load, a golden cage increases it. Teams working within a golden cage environment are continually trying to fit square pegs into round holes. Perhaps their feature requires a NoSQL database, but the platform only provides a relational database that never quite fits, no matter how much tuning they do. They have to build their feature and they simultaneously have to build the capabilities that the platform withholds..

Golden cages can arise for many reasons - technical, organizational, or both. Complex systems rarely give us clean causal chains.

One kind of golden cage emerges when going off-trail is explicitly prohibited. If developers are required to use the platform’s standard approach, even when their needs are poorly served by it, the cage is obvious.

Another emerges when opting out is theoretically allowed but practically impossible. A platform may assume backend services are written in Golang and frontends in Typescript. A team experimenting with a new AI initiative may want to work in Python, but if the platform provides no Python capabilities, that team may have to build everything from scratch, and may lack the access, time, or expertise to do so.

Golden cages also appear when organizations over-index on “day one” concerns — standing up new infrastructure — at the expense of “day two” (or “day two thousand”) concerns, such as operations, upgrades, migrations, and sunsetting. Platform resources are created once but changed many times. A platform designed for change rather than merely creation is less susceptible to solidifying into a golden cage.

Designing your platform to support a full lifecycle positions you well to deliver golden paths and avoid golden cages.

It’s not “easy,” but it is “simple.” Talk to your developers. Continually gather feedback on how well platform resources serve their needs. Give teams permission to opt out when appropriate, and build a feedback loop so that viable alternatives can be folded back into the platform. Favor standardized interfaces that allow components to be swapped out as needs evolve.

Other Posts on "Golden Paths versus Golden Cages"

Subscribe to Rarefied Err