Platform Teams: Internal Platforms That Make Business Teams Faster

A platform team builds shared capabilities such as provisioning, data access or approval routes as an internal product that business teams use on their own, without waiting. It frees the teams that deliver customer value from work that arises identically in every team. This article describes what the Team Topologies model is for, when it pays off, how to introduce it in five steps and how to recognise a platform that only slows teams down.

In many organisations business teams spend a noticeable share of their capacity on tasks that have little to do with their mission: requesting an environment, clarifying data access, connecting a reporting tool, obtaining an approval. Each of these tasks is small on its own. Together they decide whether a team delivers in a given week or waits for others.

What is a platform team?

A platform team is one of the four team types that Matthew Skelton and Manuel Pais describe in “Team Topologies” (2019). The authors distinguish stream-aligned teams, which own a continuous flow of work towards a customer or business outcome, enabling teams, which help other teams build capability, complicated-subsystem teams for areas with rare specialist knowledge, and platform teams, which provide capabilities to the other teams as a service.

The aim comes first: the cognitive load on stream-aligned teams should fall. The term goes back to John Sweller's cognitive load theory of 1988, which describes how much a person can process at once. Skelton and Pais apply the idea to teams: if a team must master deployment, monitoring and access rights in addition to its own domain, less attention is left for the customer.

The attitude of the platform team matters. In 2018 Evan Bottcher described a good platform as a set of self-service offerings that are attractive for teams to use because they make those teams faster. It follows that a platform team runs its platform like a product, with customers, feedback, a sequence of improvements and a measure of user satisfaction.

Which platforms exist outside IT?

Internal platforms exist wherever several teams need the same capability, and the model is not limited to IT. A data platform provides vetted datasets and analysis tools. A contract platform bundles templates, approval routes and storage for all sales teams. An HR platform lets business units start hires and role changes in a fixed flow by themselves. In every case the platform replaces recurring one-off coordination with a service that has a clear interface.

The model is also relevant for AI initiatives. If every department builds its own access to language models, its own data rules and its own integration, many parallel solutions of varying quality appear. A shared base that bundles access, connection to company data and approval routes lets business units build applications faster. How teams can be cut around flow in general is described in the article on Team Topologies.

When does an internal platform pay off?

An internal platform pays off when the capacity it frees in the business teams exceeds the capacity of the platform team. The calculation has three steps. First, determine for each business team the share of working time that the shared capability ties up today, including waiting time for others. Then multiply this share by the number of teams and the team size. Finally, weight the tied-up capacity by the share of teams that actually use the platform and subtract the capacity of the platform team.

The following example is illustrative. Ten business teams of six people each tie up 15 per cent of their capacity in a shared capability.

The calculation shows two things. First, the balance is narrowly positive at ten teams, clearly positive at twelve teams with the same load (plus 1.5 full-time equivalents) and negative at eight teams. With five people in the platform team and 15 per cent of capacity tied up, the threshold therefore lies at about ten teams with the same capability; below that, a business team with an advisory remit or an enabling team is enough. Second, the platform works mainly through lead time. When a team no longer waits three weeks for access, every delivery of that team gets shorter. The article on flow metrics describes which measures make this effect visible.

How do you recognise a platform that slows teams down?

A platform slows teams down when they avoid it or use it only because a rule demands it. The platform team then becomes a department with a right of approval, and teams are back to filing requests. Skelton and Pais offer the counter-model of the thinnest viable platform: it starts with the smallest set of services that visibly takes work off the teams and grows along demand.

The step from level 2 to level 3 is the critical one. At level 2 every use is still a conversation; at level 3 it becomes a self-service flow. A platform team that does not make this step remains an advisory team with a queue.

How do you introduce platform teams in five steps?

You introduce platform teams by measuring the bottlenecks first, then selecting a single capability and building it as a product. The five steps apply to IT-related and functional platforms alike.

1. Make the bottleneck visible: measure in the business teams how much working time and waiting time hang on recurring capabilities. The calculation above gives the priority.
2. Choose one capability: start with the capability that affects most teams and can be offered as self-service within a few weeks.
3. Staff the team: the platform team needs a product owner who sees the teams as customers, and specialists who build and run services.
4. Define the interaction: agree how business teams and the platform team work together. Skelton and Pais distinguish three modes: collaboration for new capabilities, service use for the standard case, temporary facilitation for hard cases.
5. Measure the effect: track adoption, waiting time for the capability and team satisfaction. End or change services that nobody uses.

The test questions for every platform team are short: which business teams need the capability, and how much time does it cost them today? Can a team use the service without a ticket? Who decides the order of improvements? How will you see after 90 days that teams deliver faster? Over time the question of dependencies also matters, which the article on dependencies between teams covers.

What is the model not suited for?

The model is not suited for capabilities that only one team uses, nor for areas in which no team has time to collaborate. A single team that needs a capability is best off solving it itself. Where business teams are so heavily loaded that they cannot give feedback, a platform without customers results. In both cases the founding costs capacity that achieves more elsewhere.

Platforms and business teams with Niehues Consulting

Niehues Consulting is a consultancy for AI management and organisational design from a delivery perspective, based in Düsseldorf. Founder Marin Niehues builds organisations that deliver, in projects from VC-funded scale-ups to DAX 40 groups and in more than 20 countries on six continents. In the organisational design service area the work covers team structure, roles, decision paths and interfaces; in delivery management it covers the steering of delivery across teams.

The approach follows the Niehues Delivery Model with three phases. Three of its test questions matter most for platform teams: who decides, who delivers, who uses? Which roles, decision paths and interfaces does operation need? Who is responsible for operation from day one? Scope and terms of an engagement are discussed in the free initial consultation, which you can arrange in 30 minutes through the contact form.