How should platform work be organised as an organisation grows, and what structure prevents the platform becoming a bottleneck?

The structure

Platform teams providing self-service capabilities, stream-aligned teams consuming them, and enabling teams building capability temporarily where deep expertise is needed.

Platform teams own capabilities as products with APIs and templates — not as a service desk. The interface is an API and a template, not a request form, and that single property determines whether the platform scales or becomes the ceiling on everyone else's throughput.

Enabling teams are the mechanism that prevents the bottleneck in the cases self-service cannot cover. They work alongside a stream-aligned team temporarily to build capability, then leave — so expertise transfers rather than being permanently requested.

This is the answer to "we still need deep database or security expertise" that does not recreate a queue.

Complicated-subsystem teams for genuinely specialist components that cannot reasonably be owned by a stream team.

What prevents the bottleneck

• Self-service for everything routine, with the request queue categorised: should be self-service (build the automation) · a missing capability (a product gap) · genuinely bespoke (rare). If the first dominates, it is an automation gap and adding platform engineers will not fix it.
• Explicit variation points, since requests are frequently a signal of rigidity rather than neediness.
• Published SLOs and a roadmap, so teams plan rather than escalate.
• Migration owned by the platform, so adoption does not depend on consumers' priorities.

The sizing signal

If serving more teams requires proportionally more platform engineers, the platform is a service desk and the economics will not work at the next scale. A platform scales when the marginal cost of an additional consuming team approaches zero.

The organisational caution

Splitting the platform into many small teams by technology — a networking team, a compute team, an observability team — recreates the layered-team problem: a stream team needing a service now needs three platform teams, and Conway's Law makes the platform's interfaces mirror that split rather than the consumer's need.

Organise platform teams around the consumer's unit of work, not around the infrastructure's structure.