Why Platform Engineering Teams Become Bottlenecks at Scale

If you run a platform engineering team, you already know this feeling.

Your team was created to build infrastructure, improve developer experience, and ensure reliability at scale.

Instead, you spend most of your time answering questions.

• "Who owns the User type?"
• "Can I add a field to the Product entity?"
• "Is shippingStatus or deliveryStatus the right naming convention?"
• "Team A and Team B both want to add a priority field. Who goes first?"

You've become a switchboard. Every API change in the organization flows through you because nobody else has the full picture.

Platform teams don't start as bottlenecks. They start as enablers.

In the early days, the team sets up the infrastructure: the router, the CI/CD pipeline, the schema registry, the observability stack. There are 5 subgraphs, maybe 10. Three teams. Coordination happens naturally.

Then the organization grows.

15 subgraphs. 30. 50. New teams are onboarded who don't know the conventions. Someone adds a field called isAvail next to isAvailable. Another team creates a CustomerInfo type when Customer already exists.

The platform team starts doing schema reviews. Then design consultations. Then ownership arbitration. Then they're spending 80% of their time on coordination and 20% on the work they were hired to do.

Platform teams end up filling three roles that were never part of the job description:

The platform team knows the answer because they set up the graph. But there's no self-service way for anyone else to find out. So every question comes to them.

A team with 100 subgraphs and 30 engineering teams might handle dozens of these routing questions per week. Each one takes 5-10 minutes. Multiply that across 30 teams and it's a significant chunk of someone's week.

Schema design reviews are important. I recently wrote a blog post on the principles behind GraphQL schema design because these decisions affect every consumer of the API.

But when every change requires a platform team review, that queue can become the gating factor for the entire organization. Teams wait days for review, while some may end up skipping the review and shipping anyway. Quality suffers either way.

"Team A is adding expressShipping to User. Team B is adding shippingOptions to User. They don't know about each other."

The platform team sees both changes, has to identify the conflict, bring the teams together, and facilitate a resolution.

This is critical work. It's also not scalable. As the number of teams and subgraphs grows, the number of potential conflicts grows quadratically.

The instinct is to hire more platform engineers. But capacity isn't the bottleneck. Information asymmetry is.

The platform team is overwhelmed because they're the only ones who can answer questions about ownership, conventions, and conflicts. It's fundamentally a cognitive load problem: the team is carrying context that should be distributed.

Adding more people to the team means more people who can answer questions. But the questions still all end up with the same team.

The fix is making the information accessible so that the questions don't need to be asked in the first place.

Imagine every engineer in the organization could:

• See the full graph — all types, all fields, all relationships
• See who owns what — every entity and subgraph
• Propose changes directly — without going through the platform team
• See who's affected — which teams need to review a proposed change
• Follow conventions — with automated checks for naming, structure, and compatibility

The platform team's role shifts from answering questions to setting standards.

Instead of reviewing every change personally, they define the rules. The tooling then enforces those rules. The platform team handles exceptions and edge cases — the stuff that needs them

This is the difference between being a switchboard and a standards body.

When the platform team isn't spending 80% of their time on routing and reviews, something interesting happens. They can focus on what moves the organization forward:

• Reliability — improving uptime, reducing incidents, better observability
• Performance — query optimization, caching strategies, infrastructure efficiency
• Architecture — evolving the graph structure as the business evolves
• Enablement — building tools and patterns that make other teams more productive

This is what platform engineering was supposed to be. Not a ticket queue for "who owns this field?" but a team that makes the entire organization better at building APIs.

We work with platform engineering teams at organizations of all sizes. The pattern is remarkably consistent:

Under 20 subgraphs: Coordination is informal. The platform team is productive. Things work.

20-50 subgraphs: Coordination starts to strain. The platform team spends increasing time on reviews and routing. Some inconsistencies creep into the schema.

50-100 subgraphs: The platform team is the clear bottleneck. Schema changes take weeks so teams start working around the process by shipping without review, creating duplicate types, or just not adding capabilities they need because the process is too slow.

100+ subgraphs: Without tooling, the system breaks down. Either the platform team becomes a massive org in itself, or schema quality degrades significantly.

The threshold varies by organization, but the dynamic is always the same: as the graph grows, coordination cost grows faster than capability. That's the missing layer in Federation .

The single highest-leverage change you can make is making ownership visible and self-service.

When a frontend engineer can open a visual canvas, see the User type, see that it's owned by Team A, see that Order is owned by Team B, and see exactly who to talk to about adding a field, then they don't need to ask the platform team.

When they can propose a change and the tooling automatically identifies which teams need to review it — the platform team doesn't need to be the router.

When naming conventions are codified as automated checks, the platform team doesn't need to review every field name.

This is what we built Hub to do.

To give platform teams back the time they need to do the work they were hired for in the first place.

If you're on a platform team feeling this pain, here's a diagnostic question:

If the answer is "more than half," the problem is visibility.

Make the graph visible. Make ownership explicit. Make the process self-service.

Your platform team will thank you.

Frequently Asked Questions (FAQ)