A platform team is overwhelmed by requests and product teams complain about waiting. What does the boundary between them need to change?

The diagnosis

The platform is operating as a service desk rather than as a product. Every request is a ticket, so the platform team's capacity is the ceiling on everyone else's throughput — which is exactly the bottleneck a platform exists to remove.

The symptom is a request queue. The cause is that the platform's interface is a conversation rather than an API.

What has to change

1. Self-service for everything routine. Provisioning, configuration, access, scaling. A team should be able to get what it needs without the platform team's involvement. A platform requiring a ticket is the old bottleneck with a new name.

2. The platform's interface is an API and a template, not a request form. That is the structural change; everything else follows from it.

3. Explicit variation points, so a team with a slightly different need can adapt within the road rather than leaving it. Requests are frequently a signal that the platform is too rigid, not that teams are needy.

4. Categorise the request queue. Requests fall into three groups, with different responses: - Should be self-service — build the automation. - Indicates a missing capability — a product gap to prioritise. - Genuinely bespoke — rare, and appropriate for the platform team to handle.

If the first category dominates, the platform has an automation gap rather than a capacity problem, and adding people to the team will not fix it.

5. Publish SLOs and a roadmap, so consuming teams can plan around the platform rather than escalating.

The organisational addition

Enabling teams — platform engineers who work alongside a product team temporarily to build capability, then leave. This addresses the "we still need deep expertise" case without recreating the bottleneck, because the expertise transfers rather than being permanently requested.

The measure

Time-to-first-success for a new team, and the proportion of platform work that is self-service versus ticketed. The second number falling over time is the only reliable evidence that the platform is scaling rather than absorbing.

If adding platform engineers is the only way to serve more teams, the platform is a service desk, and the economics will not work at the next scale.