Platforms Are Paved Roads, Not Walled Gardens

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 is the metric that proves the platform’s value.

This is the wrong starting point. Adoption is a downstream effect, not a goal. When a platform earns its place, adoption follows because the platform is the easiest path. When a platform fails to earn its place, adoption has to be enforced — and enforced adoption produces shadow IT. The teams that adopt under duress route around the platform the moment the duress lifts. The platform looks adopted in the dashboard and abandoned in the code.

The better frame is the road, not the wall. A platform is a paved road for the way most product teams want to work. It is paved because the platform team poured the asphalt, marked the lanes, lit the path, and put up signs. It is a road because anyone who needs to go somewhere it does not reach can leave it. The platform is the default. It is not the only option. A platform that cannot be bypassed is a platform nobody trusts, because the people who would need to bypass it are not allowed to admit they need to.

The paved road

The metaphor is older than the platform-engineering vocabulary. It enters software engineering through site reliability culture in the 2010s, but the underlying idea is the urban-planning one: most journeys in a city share a small set of common routes, and paving those routes well makes the city work for everyone. The roads are not mandatory. Walking across a meadow is allowed. But the road is faster, safer, and well-lit, so it is what people choose for most journeys most of the time.

A platform is the well-lit version of the most common product-team journeys. Provisioning a new service. Standing up a database. Wiring observability. Setting up CI. Deploying to staging. Promoting to production. Rotating secrets. Handling on-call. Each of these is something product teams will do anyway. The question is whether they do it once, on the platform’s road, with all the safety and tooling that road provides — or whether they do it five times, ad hoc, across teams that have each invented their own version.

The road is paved by the platform team. The teams that walk it are the platform team’s customers. The platform team’s relationship with its customers is the same as any product team’s with its users: understand what they need, ship it, improve it. The metric that matters is not adoption. The metric that matters is whether a product team that uses the platform ships faster, with fewer incidents, with less time spent on undifferentiated infrastructure work, than a product team that does not. If the answer is yes, adoption follows. If the answer is no, no amount of mandate will produce real adoption.

Default-yes, not mandatory-yes

The distinguishing property of a paved road is that it is default-yes. New work starts on the road unless there is a specific reason to leave it. The default is the path of least resistance. It is the answer when nobody has asked a different question. A product team that needs a new service runs the platform’s “create service” generator, gets a service wired into CI, observability, secret storage, and deployment automation, and is producing code in an afternoon. The road is paved well enough that the product team’s first impulse is to use it.

A mandatory platform is different. A mandatory platform makes its road the only one. Product teams that need something the road does not provide either go without or wait for the platform team to provide it. The waiting is what produces shadow IT. A product team with a deadline and a need the platform does not meet will not wait. They will build their own version of whatever the platform should have provided, in a corner of the codebase the platform team will not look at, and the platform team will discover it during a security audit eighteen months later.

The default-yes platform avoids this failure by offering an exit. Need a database the platform does not support? The platform documents how to provision one outside the platform, with the platform’s observability hooks pre-wired so the team does not lose insight. Need a deployment topology the platform’s CI does not handle? The platform documents how to fall back to a lower layer, with the platform team’s blessing rather than its disapproval. The exits are part of the road, not signs of failure of it. They tell the team where to leave the road when they have to, and they preserve the team’s ability to come back later.

Platforms that grow accept that their road will not cover every journey. Platforms that stagnate believe their road must.

The exit-path

The exit-path is the platform’s most underrated artifact. It is documented. It is supported. It is treated as a first-class shape of work, not as a deviation. The exit-path tells product teams: when you have to leave the road, here is how you do it without losing the things the road was providing. Here is how to keep observability. Here is how to keep deployment automation. Here is how to keep secret rotation. Here is how to keep the security posture you had on the road.

A team that takes an exit is still a customer of the platform. They have selected a different journey, but they have not opted out of the platform’s value. The platform team’s job is to make sure the exit does not feel like a defection. A defection model produces shadow IT. A first-class exit model produces a healthy mix of platform usage and explicit, supported deviations.

The exit-path also feeds the platform’s roadmap. Every exit a team takes is data. If three teams have taken the same exit, the road should probably be paved to that destination. If one team has taken an exit nobody else needs, the platform’s coverage is fine — that journey is genuinely an outlier. The platform team that watches its exits learns where the road needs to extend. The platform team that punishes exits learns nothing.

Platform teams are product teams

The discipline becomes coherent when the platform team treats itself as a product team whose product is internal. The other product teams are the users. The platform team has a roadmap, a discovery practice, an incident channel, a quality bar, an SLA, a release cadence. The fact that the customer is internal does not change the obligation. If anything, it raises it: an external customer can choose a different vendor; an internal customer often cannot.

Product teams treat their customers as humans with finite patience and explicit alternatives. The platform team has to do the same. The platform’s competition is not another vendor. The platform’s competition is the product team’s willingness to build a replacement when the platform is not good enough. If the replacement is faster, easier, or more reliable than the platform, the platform has lost — even if the dashboard shows ninety percent adoption.

Platform work is product work. User research applies. Interview product teams about their journeys, not their checkmarks. Find the friction points. Ship to remove them. Measure how much time the platform actually saves, not how many services have its label. The teams that get this right end up with platforms their customers brag about. The teams that treat platform work as plumbing end up with platforms their customers tolerate.

Measuring adoption without measuring lock-in

The metric that breaks platforms is adoption percentage. Targeting adoption percentage produces lock-in features. Lock-in features make leaving the platform painful, which lifts adoption — until the next product team chooses to build outside the platform from day one to avoid getting trapped. The metric incentivizes the failure mode it claims to prevent.

The metric that works is time-to-value. How long from a team’s first interaction with the platform to shipping the thing they came to ship. A new service running in production. A new database serving traffic. A new deploy pipeline running clean. The platform’s job is to make that number small and keep it small as the platform’s surface area grows. If the platform’s time-to-value gets worse over time, the platform is accreting complexity faster than it is paving roads. If it improves, the platform is doing its work.

A secondary metric is cost of exit. How much work does it take a team to migrate off the platform if they need to? Cost of exit measures lock-in directly. A platform with high time-to-value and low cost of exit is trusted. A platform with high time-to-value and high cost of exit is captive. The captive version produces adoption percentages that look good and engineering teams that resent the platform privately. Trust outlives any single executive sponsor. Capture does not.

The shadow-IT failure mode

Every platform that fails fails in the same way. A mandate goes out: all new services must use the platform. Teams with deadlines and unmet needs route around the mandate. The routes are invisible at first. They show up in security audits, in incident postmortems, in onboarding documents that warn new hires about the unofficial systems they will need to learn. By the time the platform team notices, the shadow infrastructure is load-bearing, the teams that built it have moved on, and replacing it is more expensive than the platform’s mandate ever saved.

The shadow IT is not the failure. The shadow IT is the symptom. The failure is the mandate that produced it. A team that needs a thing the platform does not provide will produce a shadow version regardless of policy. The only way to prevent shadow IT is to make sure the team did not need to produce it — either by paving the road to that destination, or by providing a supported exit that the team can take without going into hiding.

Mandates correlate with shadow IT. Default-yes platforms correlate with explicit, documented deviations. The deviation is visible. The shadow is not. A platform engineering practice that produces visible deviations is doing better operationally than one that produces ninety percent adoption with hidden infrastructure behind it.

The reward structure

The discipline assumes that the organization rewards the platform team for the product teams’ outcomes, not for the platform’s own metrics. A platform team rewarded for adoption percentage will optimize for adoption percentage. A platform team rewarded for product teams’ time-to-value will optimize for product teams’ time-to-value. The incentive lands where it points.

The same applies to the product teams. A product team rewarded for shipping fast will adopt the platform when the platform makes them ship faster and route around it when it does not. A product team rewarded for following the mandate will adopt the platform regardless of whether the platform makes them ship faster. The first failure mode keeps the platform honest. The second hides the platform’s failures until they become structural.

The cultural artifact is the same shape as the andon cord in production engineering. Pulling the cord costs throughput in the short term and earns better quality in the long term. Taking an exit from the platform’s road costs the platform team’s pride in the short term and earns better platform design in the long term. Both require a reward structure that survives executive impatience.

What it adds up to

A platform is a paved road. The road is paved by the platform team for the journeys most product teams want to make. The road is default-yes — the path of least resistance for new work. The road has documented, supported exits for the journeys it does not cover. The platform team treats its product teams as customers, not as subordinates. The platform’s success metric is product teams’ time-to-value, not platform adoption percentage. The platform’s failure mode is the mandate that produces shadow IT.

None of this is novel. All of it is the urban-planning insight applied to internal software. The road earns its place by being the easiest path. The wall earns its place nowhere. A platform that cannot be bypassed is a platform nobody trusts, because the people who would need to bypass it are not allowed to admit they need to.

The technologies are negotiable. The principle is not.