Platforms Are Paved Roads, Not Walled Gardens
Internal platforms work when they make the right path the easiest path, not when they make every other path impossible. The mature platform is a paved road for common journeys, guardrails for catastrophic risk, and visible exits for everything the road does not yet cover.
TL;DR. A platform is not valuable because every team is forced to use it. It is valuable because it makes the common journey faster, safer, and less mentally expensive than doing the work alone. The platform should be default-yes: the obvious path for new work. It should not be mandatory-yes: the only legal path for all work. The mature pattern is a paved road for common journeys, guardrails for non-negotiable risks, safety nets for recovery, and documented exits for legitimate deviations. Adoption is a health signal. Time-to-value is the outcome. Trust is the asset.
Most introductions to internal platforms start with adoption. How to drive it. How to measure it. How to enforce it. The platform team builds the platform. The product teams use the platform. Adoption becomes the metric that proves the platform mattered.
This is the wrong starting point. Adoption is not the point of a platform. Adoption is what happens after a platform has become the easiest way to do valuable work. A platform earns adoption when a team can start a service, provision a datastore, get telemetry, pass security checks, and reach production faster on the platform than outside it. A platform demands adoption when it cannot win that comparison honestly.
That distinction matters because forced adoption can imitate success. The dashboard says ninety percent of services are on the platform. The architecture says something else. Teams have forked the templates. Deployment scripts have private escape clauses. A database appears outside the approved provisioning flow. A machine-learning workload runs on an account nobody from the platform team monitors. The platform looks adopted at the edge and hollow in the middle.
The better frame is the road, not the wall. A platform is a paved road for the journeys most product teams need to make. It has asphalt, signs, lights, drainage, crash barriers, maintenance crews, and exits. It is designed so the normal journey is boring. It is not designed so leaving it is impossible.
A platform that cannot be bypassed is not necessarily trusted. Often it is merely enforced. Trust appears when teams choose the road even though they know where the exits are.
The road
The platform-engineering vocabulary arrived in layers.
Evan Bottcher’s 2018 definition of a digital platform described the shape before the current wave of platform engineering had settled on its language: self-service APIs, tools, services, knowledge, and support arranged as a compelling internal product. Netflix gave this essay its central metaphor with the idea of the paved road: centrally supported tooling that teams are encouraged to use because it is safer and cheaper than building their own path, but not because autonomy has been confiscated. Spotify gave the neighboring idea its most durable name with Golden Paths: opinionated and supported ways to build software.
Those terms are often treated as near synonyms now, but the distinction is worth keeping clean. Paved road names the road metaphor most directly. Golden path names the supported route through a specific engineering journey. Google, Red Hat, CNCF, Backstage, and the broader platform-engineering community mostly use golden-path language, sometimes describing it as a paved road. The terms vary. The structure is the same: a curated internal path that reduces duplication and lets teams move faster without having to relearn infrastructure every week. The CNCF Platforms White Paper uses the same center of gravity: platforms are integrated capabilities presented according to the needs of their users.
The metaphor works because roads are not abstract. A road exists because many people keep making the same journey. Enough feet cross the same field and the path becomes visible. Enough carts take the same route and the ground needs reinforcement. Eventually someone paves it, lights it, drains it, and maintains it. The road is not a denial of all other movement. It is an investment in the movement that already happens.
A platform is the same investment applied to software delivery. Product teams will create services anyway. They will need build pipelines anyway. They will need secrets, databases, message queues, deployment environments, alerts, dashboards, logs, rollback paths, vulnerability checks, cost visibility, and incident ownership anyway. The platform question is whether every team should rediscover those concerns locally or whether the organization should pave the common route once and improve it continuously.
The platform team’s job is not to invent a route from a diagram. It is to notice the routes teams already walk. Where do new services begin? Where do teams stall? Where do tickets accumulate? Where do engineers copy one repository into another because the official tool is too slow? Where does every onboarding document contain the same private warning: ask Alice, she knows the real way to deploy this?
Those are desire lines. They are the footpaths across the grass. The platform roadmap should begin there.
The common journey
The basic unit of platform design is not a component. It is a journey.
A component is a thing the platform offers: a template, a Terraform module, a Kubernetes abstraction, a deployment pipeline, a secret store, a dashboard, a policy engine. Components are necessary, but product teams do not wake up wanting components. They want to get somewhere. They want a new service running in production. They want an experiment behind a feature flag. They want a database that is backed up, monitored, and compliant. They want to know why latency increased after the last release. They want to pass an audit without spending two weeks reconstructing the architecture from memory.
A platform that starts from components becomes a catalogue. A platform that starts from journeys becomes a product.
The difference is visible in the first hour of use. In the catalogue model, a developer gets a portal full of nouns: clusters, pipelines, roles, dashboards, modules. Each noun is useful, but the work of assembling them remains with the product team. In the journey model, the platform asks a more useful question: what are you trying to do? Create a service. Add a datastore. Expose an API. Publish an event. Run a batch job. Promote to production. Investigate an incident.
The paved road is the complete path through one of those journeys. A good “create service” road does not stop at repository generation. It produces a service with ownership metadata, CI, deployment automation, dependency scanning, runtime configuration, secrets access, logs, metrics, alerts, runbook links, cost tags, and a place in the service catalogue. It gives the team something alive enough to improve, not a skeleton they must spend the next sprint animating.
Spotify’s Golden Paths made this explicit. The path was not just a blessed tool. It was a tutorial, a sequence, a discoverable route through tooling, documentation, and support. The important part was not the portal. The important part was the journey becoming legible enough that a new engineer could walk it without rumor-driven development.
This is why platform work is not just infrastructure work. Infrastructure teams provide capabilities. Platform teams turn capabilities into coherent journeys.
Golden paths and guardrails
The phrase paved road becomes sloppy unless it is separated from neighboring ideas. A mature platform has at least four different control shapes: golden paths, guardrails, safety nets, and checkpoints. Google Cloud’s control-mechanisms taxonomy is useful precisely because it separates steering mechanisms from hard stops, recovery mechanisms, and human review. Confusing them is how platforms become either too weak to matter or too restrictive to trust.
A golden path is the road. It steers. It makes the right choice the easy choice. It gives teams a pre-approved route with secure defaults and low friction. A team using the road should feel helped, not inspected. The road should remove choices the team did not want to make and preserve choices the team is responsible for making.
A guardrail is not the road. It is the crash barrier. It does not exist to guide ordinary work. It exists to prevent a catastrophic action: a public storage bucket for sensitive data, an unsigned production image, a privileged container in a shared cluster, a workload in a forbidden region, a network path that breaks tenant isolation. Guardrails are allowed to be mandatory because they protect the integrity of the shared environment. Developers should rarely meet them, but when they do, the answer is no.
A safety net is different again. It assumes failure will happen and makes recovery cheap: automated rollback, backups, rate limits, circuit breakers, progressive delivery, restore drills, kill switches, disaster recovery, incident routing. Safety nets do not prevent every bad change. They prevent a bad change from becoming an unrecoverable one.
A checkpoint is where human judgment still belongs. Some changes need architecture review, threat modeling, legal approval, or operational readiness review. The mistake is treating every workflow as if it needs a checkpoint. The other mistake is pretending no workflow does. A good platform moves routine judgment into defaults and reserves human judgment for cases where context really matters.
This distinction strengthens the road metaphor. The argument is not that every constraint is bad. Roads have speed limits, lane markings, crash barriers, and bridges with weight restrictions. The argument is that the road should not become a prison. The default path can be opinionated without being totalizing. The guardrail can be mandatory without turning the entire workflow into a mandate.
The mature formula is simple: default paths for common work, hard stops for catastrophic risk, safety nets for recovery, and explicit checkpoints for genuinely judgment-heavy decisions.
Default-yes
A paved road is default-yes. New work starts there because it is the lowest-friction route. The platform does not need a campaign to persuade teams to use it every time. The value is visible at the moment of work.
A developer needs a new service. They run the generator, answer a few questions, and get a repository with a build, a deploy path, ownership metadata, observability, secret access, and a first production route. The platform does not merely create files. It compresses organizational knowledge into an experience short enough to fit inside the developer’s patience.
That compression is the product. The platform team has taken security’s requirements, operations’ requirements, finance’s tagging rules, SRE’s observability expectations, architecture’s constraints, and the developer’s need to move quickly, and folded them into a path that feels like help. That is the difference between a platform and a process document.
DORA’s recent research makes this argument less ideological. Internal developer platforms are associated with better individual productivity, team performance, and organizational performance, but they can also reduce change stability and throughput when implemented poorly or when they reduce developer independence. That is the platform problem in one sentence: the same abstraction that accelerates a team when it fits can slow the team down when it becomes another coordination layer.
A mandatory platform has a different shape. It starts with policy. All new services must use the platform. All infrastructure must be provisioned through the platform. All deployments must use the platform pipeline. The policy may be rational. The problem begins when the platform does not yet cover the real variety of work the policy tries to control.
A team with a deadline and a legitimate need will not wait forever for the road to arrive. It will solve the problem. If the official route is too slow or too narrow, it will solve it elsewhere. The work does not disappear because the platform forbids it. It moves into a corner with worse visibility.
Default-yes platforms avoid this by staying honest about coverage. The road is excellent where it exists. Where it does not exist, the platform says so. It provides a lower-level route. It documents what support is preserved and what support the team now owns. It keeps enough telemetry, identity, security posture, and ownership data attached that the deviation remains visible. The platform team can still learn from it.
Mandatory-yes platforms produce obedience first and learning later, if at all. Default-yes platforms produce learning continuously.
The exit path
The exit path is the most underrated artifact in platform engineering.
It is not a loophole. It is not a shameful appendix. It is not the paragraph that says “talk to the platform team” because nobody had the courage to define the real boundary. A good exit path is designed, documented, supported, and observable. It tells teams how to leave the road without losing everything the road was providing. This is why Red Hat’s Golden Path guidance emphasizes optionality, transparency, extensibility, and customization rather than treating the path as a cage.
Need a database the platform does not support? The exit path explains how to provision it, how to register ownership, how to attach monitoring, how backups are verified, how credentials rotate, what incident expectations apply, and what the team now owns. Need a deployment topology the golden path cannot represent? The exit path explains which lower-level primitives are supported, what policy checks still apply, and how the team can return if the platform later grows to cover that shape.
A team that exits is still a platform customer. It has not betrayed the platform. It has revealed a mismatch between the road and the journey.
This is where trust compounds. If leaving the road means losing all support, teams hide the departure. If leaving the road means preserving enough support to remain safe and visible, teams tell the truth. The platform team can then distinguish between three very different cases: a legitimate outlier, an emerging common pattern, and a road that is simply not good enough.
The first case should remain an exit. Not every destination deserves asphalt. A platform that tries to pave every possible journey becomes too wide to maintain and too complex to use.
The second case should become roadmap. If three teams have taken the same exit, the organization is no longer looking at an exception. It is looking at demand. The work has crossed the threshold from “one team being unusual” to “the road probably needs to extend.”
The third case is the hardest. Sometimes teams exit not because they need a different destination but because the road is unpleasant. The template is stale. The build is slow. The abstraction hides the wrong things. The policy errors are unreadable. The documentation is accurate but unusable. The road technically reaches the destination, but nobody wants to drive on it. That is not an adoption problem. That is a product-quality problem.
The exit path makes all three visible.
Dusty paths
Not every path is either paved or wild. Mature platforms need a middle state.
A dusty path is a capability the platform has noticed but not fully paved. It may support a new cloud service, a new runtime pattern, an AI workload, an eventing model, a data pipeline, or a deployment topology that has not yet earned full investment. The platform team can expose the path without pretending it has the same maturity as the main road.
Spotify’s own vocabulary points in this direction. Golden Paths gave rise to related ideas such as Paved Road and Silver Path. The labels matter less than the underlying maturity model: not every route deserves the same support level, and the organization needs names for the difference.
This matters because platforms live in changing environments. Product teams discover new needs. Cloud providers release new capabilities. AI changes the shape of development and operations. Data workloads collide with application platforms. Security expectations evolve. A platform that only offers fully paved roads will always lag reality. A platform that offers every new thing as if it were mature will dilute trust.
The dusty path gives the organization vocabulary for responsible experimentation. It says: this route exists, but it is rougher. It may lack full self-service. It may lack standard observability. It may require more team ownership. It may not yet have an automated recovery story. Use it with eyes open.
That honesty is better than the two common alternatives. The first alternative is prohibition, which pushes teams into shadow systems. The second is premature paving, which turns every experiment into a permanent platform commitment. Dusty paths preserve motion without lying about maturity.
They also create a healthier innovation loop. Teams can try something new without asking the platform team to industrialize it first. The platform team can watch which experiments repeat. Repetition turns dust into asphalt. Lack of repetition lets the path fade without embarrassment.
A good platform is not only a road network. It is also a way of deciding which tracks deserve to become roads.
Product teams, not priests
The platform team is a product team. Its product is internal, but the word product still matters.
A product team has users. It has journeys. It has discovery. It has a roadmap. It has support channels. It has release notes. It has onboarding. It has usability problems. It has competitors, even when the organization pretends it does not. Team Topologies gives this shape an organizational name: a platform team provides a compelling internal product that accelerates stream-aligned teams.
The platform’s competitor is not another vendor. The platform’s competitor is a product team’s ability to do the work without it. That competitor is always present. It may be slower, riskier, and more expensive over time, but it is usually faster this week. This week is where platforms lose trust.
This is why the criticism that platform engineering is just rebranded DevOps sometimes lands. When a platform team only changes the title on the old operations queue, the critique is fair. A platform is not a team rename. It is an operating model change: from ticket handling to product management, from standards as instruction to standards as usable defaults, from enforcing workflows to improving journeys.
A platform team that forgets this becomes priestly. It explains the approved way. It enforces standards. It interprets policy. It treats deviation as impurity. The users become supplicants. The backlog becomes a queue of exceptions. Every unusual request is evidence that the product teams lack discipline.
A product-minded platform team reads the same signal differently. A support request is a usability defect until proven otherwise. A forked template is product feedback. A repeated manual step is a missing feature. A shadow deployment is not only a governance issue; it is evidence that the official route did not meet the need in time.
This does not mean the platform team says yes to everything. Product teams say no constantly. They say no because they understand their product’s purpose, constraints, and customers. Platform teams need the same discipline. The difference is that a product no is explicit. It explains the boundary. It offers the supported alternative. It does not hide behind “because the platform says so.”
Internal customers are still customers. The fact that they cannot easily choose another vendor does not lower the platform team’s obligation. It raises it.
The scorecard
Adoption is a useful metric in the same way traffic is useful to a city planner. It tells you whether people are using the road. It does not tell you whether the road gets them where they need to go, whether the intersections are dangerous, whether the route saves time, or whether people are using it because every other route has been blocked.
The metric that breaks platforms is adoption percentage treated as a target. Once adoption becomes the rewarded number, the platform team is incentivized to increase adoption directly. That usually means making alternatives harder, not making the platform better. The dashboard improves while the system gets worse. Goodhart’s law is not a slogan here. It is the operating model.
Adoption should remain in the scorecard, but it should not own the scorecard. Retention matters. Repeat usage matters. New-team onboarding matters. But those are health signals. The outcome is whether teams deliver valuable software faster, more safely, and with less undifferentiated infrastructure work.
The better primary metrics are journey metrics. How long from request to fulfilled capability? How long from new service request to production deploy? How long from a new team joining to its first customer-facing change? How long from incident detection to diagnosis? How often does a team need a ticket from the platform team to complete a routine journey? How often does the platform give clear feedback when a task fails?
Delivery metrics matter too, but they should be used with current language and with context. DORA now describes software-delivery performance through five metrics: deployment frequency, change lead time, failed deployment recovery time, change fail rate, and deployment rework rate. The first three describe throughput. The last two describe instability. None of them should become a league table. They are diagnostic instruments, not trophies.
Developer experience matters because the whole point of a platform is to reduce the cognitive cost of safe delivery. SPACE is useful because it refuses the fantasy of one productivity metric. DevEx is useful because it names feedback loops, cognitive load, and flow state as first-order concerns. DX Core 4 is useful because it keeps speed, effectiveness, quality, and impact in tension. The names matter less than the balance. A platform scorecard should contain tension by design.
The platform should also measure the cost of controlled deviation. Not the cheapest possible exit. An exit that loses auditability, ownership, security checks, and observability is cheap only because the bill has been moved to the future. The useful question is narrower: how hard is it for a team to step off the paved road for a legitimate reason while preserving the minimum safety and visibility properties the organization needs?
That is a trust metric. Low cost of controlled deviation means the road is confident. High cost of controlled deviation means the road is defended by captivity.
Shadow IT
Shadow IT is not always the disease. Often it is the symptom.
The disease is unmet demand plus a sanctioned path that is too slow, too narrow, too cumbersome, or nonexistent. People do not usually create unofficial systems because they enjoy governance risk. They create them because there is work to do and the official route is not helping them do it. NIST’s shadow-IT guidance describes the same mechanism: staff often resort to shadow IT when enterprise systems are cumbersome, impede work, or fail to provide necessary capabilities.
This pattern is older than cloud platforms, but the current AI wave made it obvious. Microsoft’s 2024 Work Trend Index found that 78% of AI users were bringing their own AI tools to work while many leaders still lacked a clear implementation plan. That is the same organizational pattern in a different costume: when the sanctioned path lags behind the work, people create their own path and then hide it, especially once coordination becomes the limiting factor.
DORA’s 2025 AI-assisted software-development research points in the same direction from another angle. AI does not fix the organization underneath it. It amplifies what is already there. If the platform is clear, self-service, observable, and trusted, AI has a cleaner system to accelerate. If the platform is confusing, slow, and punitive, AI accelerates the workarounds too.
The security problem is not merely that the unofficial path exists. The security problem is that the unofficial path is invisible. Unknown systems cannot be patched consistently, audited properly, monitored effectively, threat-modeled honestly, or retired safely. They become load-bearing before anyone with enterprise responsibility knows they exist.
A platform mandate often claims to prevent this. It can do the opposite. If the mandate says “all work must use the road” and the road does not reach the destination, the team does not stop needing the destination. It stops admitting the journey.
The mature response is to convert invisible shadow into visible deviation. That does not mean blessing every workaround. It means giving teams a supported way to say: the road does not reach this place yet, so here is the route we are taking, here is the ownership model, here is the risk, here is the telemetry, here is the recovery story, and here is the condition under which we come back.
A visible deviation is governable. An invisible workaround is folklore with production traffic.
The reward structure
Every platform has an architecture, but it also has an incentive system. The incentive system usually wins.
Reward the platform team for adoption percentage and it will optimize for adoption percentage. It will make the road sticky. It will make exits expensive. It will push for mandates because mandates improve the number quickly. It may still use the language of developer experience, but the real customer has become the metric.
Reward the platform team for product-team outcomes and its behavior changes. It becomes interested in time-to-value, task success, support load, delivery health, recovery time, and the quality of the most common journeys. It wants teams to use the platform because that is the shortest path to their goal. It treats exits as product feedback because exits affect outcomes. It improves the road because the road’s usefulness is what moves the real measure.
The same is true for product teams. A team rewarded only for local delivery speed will route around the platform when the platform slows it down. That can be painful, but it keeps the platform honest. A team rewarded for compliance theatre will use the platform even when it makes delivery worse, then build unofficial supplements in private. That is worse. It hides the truth from both sides.
The organizational art is to reward the truth early. Pulling an andon cord on a production line costs throughput now and protects quality later. Taking a platform exit has the same shape. It may embarrass the platform team now, but it protects the platform from mistaking mandate for fit. Both only work when the culture rewards the person who reveals the problem.
This is where platform engineering stops being a tooling discussion. The tools can be excellent and the reward structure can still destroy the platform. A culture that punishes exits will get fewer exits and more shadow. A culture that studies exits will get better roads.
What it adds up to
A platform is a paved road. The road exists because many teams keep making the same journey. The platform team’s job is to make that journey faster, safer, clearer, and less cognitively expensive than doing it alone.
The road is default-yes. New work starts there because the path is obvious and useful. The road is not mandatory-yes. When the journey does not fit, the team needs a documented exit, a dusty path, or a lower-level route that preserves enough safety and visibility to keep the organization honest.
The platform has guardrails, but the guardrails are not the platform. Guardrails are crash barriers for catastrophic risk. Golden paths are steering mechanisms for ordinary work. Safety nets make failure recoverable. Checkpoints reserve human judgment for the places automation should not pretend to decide.
The platform team is a product team. Its customers are product teams. Its roadmap begins with journeys. Its strongest signal is not adoption in the abstract, but whether teams reach production faster with less avoidable infrastructure work and fewer operational surprises. Adoption belongs in the scorecard, but adoption is not the score.
The exit path is not a failure of the platform. It is how the platform learns. One exit may be an outlier. Three exits may be demand. Hidden exits are the failure mode.
None of this is a rejection of standards. It is a rejection of captivity as a substitute for product quality. The right platform makes safe work easy enough that teams choose it. It keeps the rest visible enough that the organization can learn.
The technologies are negotiable. The principle is not.