When should a capability be owned by a platform team rather than by a stream-aligned team?

What is being tested

Whether you use cognitive load as the criterion, and whether you know what distinguishes a platform team from a service desk.

The criterion: cognitive load and repetition

A capability belongs to a platform team when:

1. Multiple stream-aligned teams need it, and are each solving it independently, badly and inconsistently. That duplication is the signal.

2. It requires depth that would overload a stream-aligned team. Kubernetes operations, observability pipelines, identity infrastructure. A product team should not need to be expert in these to ship a feature.

3. It can be offered as self-service. This is the decisive test. If the capability cannot be consumed through an interface without a conversation, a platform team will become a bottleneck rather than an enabler.

4. Consistency across teams has genuine value — security posture, compliance evidence, operational tooling.

When it should stay with the stream-aligned team

• When only one team needs it, so there is no duplication to remove.
• When it is domain logic, which belongs with the domain.
• When centralising it would create a bottleneck on the critical path of delivery.
• When the organisation is small. The overhead of a separate team exceeds the duplication it removes; the platform work is done by the delivery teams, and that is correct.

The distinction that determines success

Self-service, not request-based.

A platform team that performs work on request is a functional team with a new name. It preserves the handoff it was meant to remove, accumulates a queue, and becomes the organisation's delivery bottleneck — while shadow infrastructure is built to avoid it.

A platform team that provides capability teams use themselves removes the handoff entirely. That is the whole difference, and it is the thing to check when someone proposes creating one.

The interaction mode as a design tool

Most interactions should be X-as-a-service: consumed through a well-defined interface without needing to talk. Collaboration — high bandwidth, two teams working closely — should be deliberately temporary, for discovery. Two teams collaborating indefinitely is a signal that the boundary is wrong or that they should be one team.

The measure

Voluntary adoption, plus delivery outcomes for teams using the platform against those who are not: lead time, deployment frequency, incident rate, time to first deploy. That comparison is the evidence that justifies the team.

What a strong answer adds

That an enabling team is the third option and is often the right one: a team that helps others acquire a capability and then leaves. Explicitly temporary. Enabling teams that never leave become permanent dependencies, which is the failure mode of that type.