Team Topologies vocabulary, used carefully
The Team Topologies book by Matthew Skelton and Manuel Pais gives most interviewers their shared terms, and using them precisely signals you have read past the diagram. Stream-aligned teams own a flow of change to users. In Team Topologies terms, a platform team exists to reduce the cognitive load on those teams by offering capabilities they consume. The book also names enabling teams, which coach for a period, and complicated-subsystem teams, which hold rare specialist knowledge.
The distinction that matters most at executive level is the interaction mode. The book's answer is that a platform should mostly be consumed through its X-as-a-Service mode, with a documented interface and no meeting required. Close collaboration with a product team is legitimate early on, when you are discovering what to build, but it should be time-boxed. A platform group that collaborates with everyone indefinitely has become a shared dependency with a nicer name.
The triggers that justify creating one
You do not create one because the organisation reached a size. You create it when you can point at the cost of not having one. Three signals carry most of the weight, and a strong answer names how each would be observed.
The first is duplication. Four teams have each written deployment pipelines, secrets handling and service templates, and each maintains its own copy. The second is cognitive load. Product engineers spend a visible share of their time on infrastructure they do not care about, and you can see it in the work items, in onboarding time and in incidents caused by misconfigured plumbing. The third is consistency risk. A security or compliance change has to be made forty times by forty teams, and some of them never make it.
When none of these is present, the honest answer is "not yet". A company with three product teams usually gets more from an agreed set of conventions and one shared repository of templates than from carving out a team. That team would then have to justify itself by inventing work.
| Signal | How you would see it | What it suggests |
|---|
| The same capability rebuilt by several teams | Similar pipelines or libraries in several repositories | Consolidation into a platform capability |
| Product engineers absorbed by plumbing | Infrastructure work items on product boards, slow onboarding | Reduce cognitive load through self-service |
| Organisation-wide changes that never finish | Patch or policy rollouts stuck at partial coverage | A single owned path the change can flow through |
| One team doing hard specialist work | A rare skill everyone depends on | Possibly a complicated-subsystem team instead |
The last row matters. Not every shared problem is a platform problem, and putting a specialist capability inside a general platform group tends to bury it. Team Topologies treats that case separately for this reason.
The bottleneck rarely comes from bad engineers. It comes from the interface. If a product team gets a database, an environment or a pipeline change by raising a ticket, then every product team's lead time now includes the platform backlog. You have centralised the work and also centralised the waiting. Add a mandate that everyone must use the platform, and the product teams lose their only way out, while the platform loses its only signal that the service is poor.
The second route to a queue is building for imagined needs. A platform without a product owner tends to build what its engineers find interesting, or what someone predicts the organisation will need in two years. Meanwhile, the requests that matter today pile up as tickets.
The mistake that separates strong answers from adequate ones is relabelling an existing infrastructure or operations group as "the platform team" and declaring the job done. If requests still arrive as tickets and are fulfilled by hand, nothing about the dependency has changed. Only the name on the org chart has. Interviewers listen for whether you treat the change as a change of operating model: what is offered, how it is consumed, and who decides what gets built.
In practice that means a few concrete commitments you would make as the accountable executive:
- A product manager, or a senior engineer explicitly in that role, who runs user research with product teams and owns a public roadmap.
- Self-service as the definition of done. A capability is not delivered until a product team can use it without talking to anyone.
- A thinnest-viable starting point. Begin with documentation and a paved path for the most common case, and grow only where demand is proven.
- Voluntary adoption for most capabilities, with a small number of explicit, justified exceptions, such as a security control everyone must pass through.
- A visible escape hatch for teams whose needs do not fit, recorded so the platform learns from it. The golden-path page works through that mechanism in detail.
Measuring it by what it removes
A platform team that reports features shipped is reporting its own output. What you care about is the effect on stream-aligned teams. Useful measures include the share of requests fulfilled through self-service rather than tickets, the time a new service takes to reach production, the time product teams spend blocked on platform work, and voluntary adoption by teams that could have chosen otherwise. Pair these with structured interviews of users, because surveys alone tend to measure politeness. When adoption stalls, the developer portal adoption page shows how to read the number by segment rather than in aggregate.
Make the funding conversation honest too. Its value often shows up as cost avoided elsewhere, which is hard to attribute. The headcount and platform investment page covers how to price that status quo.
Staffing and the executive's own role
Staffing the first platform team usually means taking experienced engineers from product teams. Say so, and say which teams pay for it. Seed the team with people who have felt the pain as users, not only infrastructure specialists, because they will build for the user they used to be.
Your own job is to protect the operating model when pressure arrives. A product leader will ask it to build a one-off for their launch. A security incident will tempt you to mandate everything. Both are sometimes right, and both should be visible decisions with an end date rather than drift. Review each platform capability annually and be willing to close one that is not earning its cost. The team re-cut page makes the related point that a shared team consumed without a meeting reduces dependencies, while one that must be scheduled multiplies them.
A platform team is only a platform if teams can use what it offers without waiting for it. Judge it by the queue it removes, never by the one it runs.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).