Your platform team started as an enabler, but teams now complain that every new capability request sits in the platform team's backlog for months. How do you diagnose and fix this?

This usually happens because the platform team has drifted from "build reusable, self-service capabilities" toward "handle individual requests as bespoke work" — the fix is auditing what's actually consuming the platform team's time, and for anything that's really a repeated pattern of similar one-off requests, invest in making that self-service instead of continuing to handle each occurrence manually, which is the only way the platform team's effort stops scaling linearly with request volume.

The core anti-pattern is subtle: a platform team can look and feel productive — clearing tickets, building things, staying busy — while structurally becoming exactly the bottleneck it was meant to remove, if its work has drifted toward handling individual requests directly rather than building capabilities other teams can use without needing the platform team in the loop each time.

• Requests to the platform team sit in a backlog for months, with teams reporting this as blocking their own work.
• The platform team appears busy and is shipping things, but the aggregate throughput doesn't keep pace with request volume.
• Teams increasingly route around the platform team (building their own workarounds) rather than waiting for a requested capability.

• The platform team has shifted from building reusable, self-service capabilities toward handling individual, bespoke requests directly — each request consumes platform-team time proportional to that one team's need, rather than being solved once for everyone.
• Growth in the number of consuming teams has outpaced the platform team's own headcount, and nothing has changed about how work is delivered to compensate for that ratio shift.
• There's no clear prioritization framework, so the platform team is reactively working through whatever request came in, rather than strategically investing in the highest-leverage, most-reusable capabilities first.
• The platform's existing self-service capabilities don't cover enough of what teams actually need, forcing more requests to become bespoke, one-off platform-team work by necessity.

1. Categorize recent backlog items and completed work by whether each was a reusable capability (built once, usable by any team without further platform-team involvement) or a bespoke, single-team request — this reveals how much of the platform team's actual time goes to each category.
2. Check whether specific types of requests recur frequently across different teams — a repeated pattern is a strong signal that request category should become a self-service capability rather than continuing to be handled individually each time.
3. Assess the ratio of platform-team headcount to the number of consuming teams/services, and how that ratio has changed over time, to understand whether growth alone explains part of the slowdown.
4. Survey affected teams on what's actually blocking them — sometimes the perceived bottleneck is really a documentation or self-service-capability gap that looks like "waiting on the platform team" but doesn't actually need to.

1. Identify the highest-frequency request patterns and invest in making them self-service, prioritizing by (frequency × current per-request platform-team time) — this is the single highest-leverage lever, converting future occurrences from consuming platform-team time to needing none at all.
2. Establish an explicit prioritization framework (echoing product-management prioritization) so the platform team is deliberately investing in the highest-leverage work, not just working through the backlog in arrival order.
3. Communicate transparently about what's being deprioritized and why, since teams whose specific request isn't prioritized still need visibility into why, and rough timing, rather than an opaque, indefinitely-stalled backlog.
4. Consider whether headcount genuinely needs to grow if self-service investment alone can't close the gap — this is a legitimate outcome of the diagnosis, not a failure of the platform-as-product approach, but should be a data-backed conclusion, not a first resort.

• Regularly audit the platform team's own time allocation between reusable-capability work and bespoke request handling, catching drift toward the bottleneck pattern before it becomes severe.
• Build the self-service philosophy into how new capabilities are scoped from the start — asking "how would this work for any team requesting it, not just the one that asked" as a standard design question.
• Track backlog age and request volume as ongoing platform-team health metrics, not just something reviewed reactively once teams start complaining.

• A platform team can look productive while structurally becoming a bottleneck, if its work has drifted from building reusable, self-service capabilities toward handling individual requests directly.
• Categorizing recent work by "reusable capability" versus "bespoke request" reveals the actual time allocation driving the bottleneck.
• The highest-leverage fix is converting the most frequent request patterns into self-service capabilities, since that's what stops platform-team effort from scaling linearly with request volume.
• Transparent prioritization and communication matter even when the underlying fix (self-service investment) takes time to pay off — teams need visibility, not silence, while it's happening.

• Team Topologies: Platform Teams
• platformengineering.org: What is an Internal Developer Platform?