Platform Teams
Teams providing self-service internal capability to reduce the cognitive load on delivery teams — distinguished from a service desk by self-service.
Definition
A platform team builds and runs internal products that other teams consume without needing to talk to them. Its purpose is to reduce the cognitive load on stream-aligned teams so those teams spend their capacity on the domain rather than on infrastructure.
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, and it becomes the organisation's delivery bottleneck — a queue at the door, a backlog of one-off requests, and shadow infrastructure built to avoid it.
A platform team that provides capability which teams use themselves removes the handoff entirely. That is the whole difference.
What makes a platform team work
- Product thinking. Users, discovery, a roadmap, adoption metrics, documentation as a feature.
- Voluntary adoption as the measure. A platform that must be mandated is one that would not survive on its merits, and mandating it destroys the signal.
- A paved road as the primary deliverable.
- Reducing cognitive load, not shifting it. A platform requiring teams to understand more than they did before has failed, however capable it is.
- Support with a defined response expectation.
When to create one
Not immediately. In a small organisation the 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 to create one: the same infrastructure problem being solved repeatedly by different teams, badly and inconsistently, consuming capacity that should go to the domain.
The failure modes
- The ticket queue, described above.
- Building what the platform team finds interesting rather than what teams need, which is what discovery prevents.
- Owning too much, so the platform team becomes 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 who are not. That is evidence, and it is what justifies the team's existence when the question is asked.
Interview question
"When should an organisation create a platform team, and what distinguishes one from a service desk?"