When should an organisation create a platform team, and what distinguishes one from a service desk?

What is being tested

Whether you know both the timing signal and the single property that determines whether it works.

When to create one

Not immediately. In a small organisation, platform work is done by the delivery teams, and that is correct — the overhead of a separate team exceeds the duplication it removes.

The signal: the same infrastructure problem being solved repeatedly by different teams, badly and inconsistently, consuming capacity that should be going to the domain.

Concretely: three teams have each built their own deployment pipeline; four have different logging approaches; every new service takes two weeks to reach production because each team reinvents the setup.

What distinguishes it from a service desk

Self-service.

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. The symptoms are unmistakable: a backlog of one-off requests, teams waiting days for a change they cannot make themselves, and shadow infrastructure built to avoid the queue.

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 — because the service-desk version is the default outcome unless it is deliberately avoided.

What makes it work

• Product thinking — users, discovery, a roadmap, adoption metrics, documentation as a feature.
• Voluntary adoption as the measure. Mandating destroys the quality signal.
• A paved road as the primary deliverable.
• Reducing cognitive load, not shifting it. A platform requiring teams to understand more than before has failed, however capable it is.
• Support with a defined response expectation. A platform whose users cannot get help is one they will abandon.

The failure modes

• The ticket queue.
• Building what the platform team finds interesting rather than what teams need — which discovery prevents.
• Owning too much, becoming a bottleneck by scope rather than by process.
• No exit for teams with genuinely different needs, producing waivers or shadow infrastructure.
• Measured in features shipped rather than in teams' outcomes.

The measure

Lead time, deployment frequency, incident rate and time to first deploy for teams using the platform, compared with those not using it. That comparison is the evidence that justifies the team's existence when the question is inevitably asked.

What a strong answer adds

That an enabling team — one that helps others acquire a capability and then leaves — is often the right answer instead, particularly early. It transfers capability rather than creating a permanent dependency, and it is explicitly temporary.