Gartner now expects 80% of large organizations to have a dedicated platform team by end of 2026, up from 45% three years ago. The first wave of those organisations is now wrestling with a problem nobody wrote a conference talk about last year: their platform is being bypassed.
Not by renegades. By normal engineers who love their job and don't want to fight the tools. They open a terminal, type kubectl apply, and ship faster than the golden path allows. Meanwhile the platform team watches adoption dashboards and wonders why the beautiful Backstage portal has 12 daily actives on a staff of 300.
We've worked with five platform teams in the last year. Here's the pattern we see, and the fix that actually moves adoption.
1. The "paved road" metaphor is broken
The comforting story platform teams tell themselves goes like this: we pave the golden path, make it 10x faster than the DIY route, and natural selection handles the rest.
Reality: paved roads in most organisations look nothing like the metaphor. They look like a two-lane road with 11 toll booths, a mandatory rest stop every three miles, and a speed limit that only applies to people who aren't senior engineers.
The dirt path next to it? No tolls, and the engineers who know how to drive on it are the same ones who'd be setting the direction of the platform if the platform team knew who they were.
2. The three real reasons developers bypass
Every time we dig into a "nobody uses our platform" problem, the stated reason is different. The real reason is almost always one of these three:
2.1 The paved road doesn't cover their use case. The platform supports the 60% of apps that look like "stateless HTTP service with Postgres." The other 40% — the stateful workloads, the batch jobs, the ML pipelines, the legacy PHP monolith, the one Python service that needs a GPU — get zero love and have to DIY anyway. Once a team is DIY'ing, they stop checking back.
2.2 The escape hatch is secretly mandatory. The golden path works great until you need to do something slightly unusual (pin a Postgres version, change a readiness probe, add a sidecar). The "simple" escape is to fork the template and hand-maintain it — and now you have a fork, and six months later the forks outnumber the originals.
2.3 The approval loop is longer than the task. A one-line config change takes two days to get through the platform team's intake queue. The same change, done directly, takes 90 seconds. Rational engineers optimise, and rationality is not a bug you can fix with more documentation.
3. The adoption funnel nobody measures
Here's the uncomfortable truth: most platform teams measure the wrong thing. "The platform has 99.99% uptime" is a vanity metric — nobody abandons a platform because it was down for six minutes last quarter. They abandon it because the last time they tried to use it, the experience sucked, and they found a faster way.
The metric that actually matters: what fraction of new services launched this quarter were on the golden path? If the number is under 50% and your platform has been live for more than six months, you have an adoption problem, not an availability problem.
4. The pattern that actually works
Build a developer council, not a platform team. Put 4–5 senior developers from product teams on a rotating council that actually decides what goes in the golden path. The platform team serves them, not the other way around. Without this, priorities drift to "what the platform team finds interesting," which is a different thing than "what developers need."
Measure adoption, not availability. Publish a weekly dashboard: % new services on the paved road, % bypasses, top three bypass reasons. Show it to leadership. Treat bypasses as product feedback, not as rebellion.
Make the escape hatch a first-class citizen. Don't fight bypass — absorb it. If a team needs a custom Helm chart, give them a reviewed escape hatch with explicit ownership, an SLO, and a promotion path back to the main road when the platform catches up. Shadow IT that the platform team knows about is infinitely better than shadow IT it doesn't.
Ship for the "weird 40%" early. Stateful workloads, batch, ML, GPUs. Don't polish the stateless path to perfection while the edge cases wait. The platform that ignores the hard cases is the platform that gets bypassed first — and bypass habits are sticky.
5. The anti-patterns that kill platforms
- Buying Backstage in Q1 and declaring victory in Q2 without a developer council.
- Treating "internal customers" like internal customers. They're captive, not customers — the obligation runs the other way.
- Requiring every service to migrate by an arbitrary quarterly deadline.
- Building features the team wanted, instead of features that were actually requested.
- Rewriting the deployment pipeline every 8 months because Platform V2 is always better.
- Letting the intake queue become the rate limit on the entire engineering org.
The takeaway
Platform engineering is not a tooling problem. It's a product management problem, with the uncomfortable twist that your "customers" can't leave. That twist makes it harder, not easier — because their dissatisfaction shows up as quiet bypass instead of churn.
If your IDP is technically sound but adoption is stuck, you don't need another tool. You need a product mindset, a developer council, and a weekly habit of measuring what actually matters. The paved road has to be the fastest road, for real, not just in the demo.
Is your platform team shipping but your developers aren't adopting? That's the conversation we have most weeks. Book a free 30-minute platform review — we'll look at your golden path, your bypass rate, and your intake queue and tell you honestly where the friction is.
Related: DevOps Engineering services · Engagement pricing · Three Kubernetes migration mistakes