Platform teams became the new gatekeepers we said we hated

We killed the ops silo. Then we gave it a golden path and a nicer logo. The platform team was meant to solve our problems. Somehow it became the same disease with a Backstage portal on top.

The pitch we all bought

Team Topologies sold platform teams as a way to reduce cognitive load. According to Gartner, 80% of large engineering organizations will have platform teams by 2026. This is an increase from 45% in 2022.

But here's the tension nobody wants to name. "You build it, you run it" and "let the platform team handle it" are pulling in opposite directions. You can't advocate ownership and then have all deploys funnel through a dedicated team of specialists. Gotta choose one.

The bottleneck came back wearing a hoodie

We disliked the ops team because of the never-ending ticket queue. If you needed a database, you had to submit a request and then wait for someone from another department to approve and create it for you. Platform engineering was supposed to bring self-service. But the State of Platform Engineering Report (Volume 4) reports that 45.3% of platform teams highlight developer adoption as the biggest challenge. Why? Well, 36.6% depend on top-down mandates to coerce developers to use their platform and not because they actually want to. 😬 Well, it's more like the compliance coach with a big stick.

Rachel Sweeney got it right, as quoted by Brian Bensky in his Fairwinds article from July 2025: You will always be forced to react to their needs if you impose the use of your abstractions on the team. The ops silo is reactionary. It's the same email but a different sender.

The portal is not the platform

According to Kellton Tech, Spotify's IDP solution - known as Backstage - holds an approximate 89% market share amongst IDP adopters. We can assume that every organization is currently engineering a stunning developer portal.

Here's the trap. You create a fancy UI, but the functionalities behind it, are still dependent on manual platform team approval. Simply press the button, a human will arrive shortly. Well done! You successfully redesigned the ticket queue, using improved CSS.

Charity Majors, CTO of Honeycomb, advocates for "guardrails over gatekeepers." She cautions that strict abstractions lead to "more abstraction pain" and prevent developers from being able to debug their code. Because the platform obscures everything, your engineers are unable to remedy their own incidents. They open a ticket. Rinse and repeat.

Why the shiny platform still fails

The failure rate is extremely high when looking at the numbers. The report revealed that 78% of platforms that attempt to address all developer issues and challenges right from the start eventually collapse. It appears that the new big-bang platform is essentially the new big-bang rewrite in a different guise. And it gets even worse than that. 29.6% of platform teams don't measure success at all.

If you're not keeping track of developer friction, you won't notice the line that's starting to form. Instead, you'll mistakenly think you're brilliant, all while your users find ways to bypass you.

What actually separates a road from a wall

I have seen this happening within my team. The day you start needing permission from a so-called "platform", you've already been defeated. Here's the line I keep coming back to:

• A platform you can bypass is a road. A platform you must use is a wall.
• If adoption needs a mandate, your product is bad. Fix the product, not the policy.
• Guardrails let people move fast and warn them at the edge. Gatekeepers make them stop and knock.
• If devs can't debug through your abstraction, you didn't reduce cognitive load. You hid it.

Effective platform teams I have encountered function as an in-house product organization. They strive to be chosen. They lose prospects due to being sluggish, which is painful, but it motivates them to improve. The ones who are not good will always bring up organizational policy to justify their actions. That's how you can tell they are not to be trusted.

The uncomfortable takeaway

The issue is not platform engineering. The issue is renaming centralized control to "reducing cognitive load". Responsibility was reallocated to a dedicated team and we were still shocked when the blockage reappeared. 🎯 Changing the name and creating a portal isn't enough to break down a silo. You have to create such a smooth and efficient process that nobody has a reason to work in isolation.

Here's a question for you: Do developers opt-in to using your platform team, or are they instructed to use it? If it's the latter, what would happen if you made it optional tomorrow?