Your Platform Team is not a Platform Team

Please mind the gap between the Complex Subsystem Team and the Platform.

Photo by Charles Forerunner on Unsplash

A common pitfall in many organisations is the confusion between Platform Teams and Complex Subsystem Teams, as delineated in Team Topologies. Although they share superficial similarities, their core functions and impacts are very different.

Both Complicated Subsystem and Platform Teams typically expose APIs that other teams can interact with. They often provide capabilities that can be used or leveraged across different products. But that's it. In essence they are very different.

For instance, a common misconception I've seen is labelling ‘search and recommendation’ teams as Platform teams. In full honesty, there is a way this could be a Platform team, but I'll leave that explanation for later.

OK, now let's go with some definitions.

The essence of a platform team

Platform Teams are responsible for creating and maintaining internal services and tools designed to be used by Stream-aligned teams within the organisation. They act as a force multiplier, enabling other teams to deliver value more quickly by reducing cognitive load and eliminating the need for them to solve common or complex problems from scratch.

From this definition, we can distill the following key concepts and characteristics:

• Service-Oriented: They Provide services to other teams like APIs, infrastructure provisioning, deployment tooling, or data platforms.

• Internal Focus: The platform is not a product sold externally but is used internally to accelerate development.

• Enabling: The platform offers capabilities that enable other teams to build and release their products more effectively and efficiently.

• Standardisation: Promotes best practices and standardisation across the organisation for technology, security, and operations.

Consider this helpful rule of thumb: While a Stream-aligned Team could operate independently, effectively utilising a Platform Team's services can significantly boost their efficiency and value delivery.

They could most likely do it on their own. By leveraging those platform capabilities though they reduce cognitive load, and they can deliver that same value more quickly.

Not a must have, but - if the Platform Teams are doing a good job - a hell of a good nice to have!

Let's now flip the coin and look at the other side.

The essence of a Complicated Subsystem Team

Complicated Subsystem Teams are tasked with building and maintaining parts of the system that require specialised knowledge and expertise due to their complexity: advanced algorithms, data processing, regulatory compliance, etc

If we break this down in some key concepts, this is what characterises Complicated Subsystem Teams:

• Specialisation: Team members have specialised knowledge necessary to deal with the subsystem’s complexity.

• Focused Scope: Works on a specific set of problems within the larger system that are too complex for a Stream-aligned team to handle within their cognitive load.

• Isolation: This team's work is often isolated from the frequent changes happening in other parts of the system.

• Clear Interfaces: Provides clear and stable APIs or interfaces to their services to be used by other teams.

The rule of thumb here becomes: Without the services offered by this team, a Stream-aligned Team will be severely limited in their ability to deliver business value in certain categories, and they will need to find those capabilities elsewhere. This usually comes in the form of either hiring the missing specialists, or finding a third party vendor that offers such a capability as a a service.

The Search Example

I referred to 'Search' as a common example where the term 'Platform' is often conflated, and I know I owe you some explanations, sir.

So, as Clint Eastwood would say, there are two types of Search team in the world

Type 1: a Search team offers a managed version of a search engine, let's say Elasticsearch. The Platform team will likely offer value added capabilities such as autoscaling, out-of-the-box observability, backup, security as well as tooling to simplify the tasks of maintaining datasets. They abstract away all the infrastructure complexity while not imposing any limitations on how Stream-aligned teams will leverage the service.

These can freely define their schemas, indexes, and data integration methods to feed the search engine.

In this case the Search team is operating as a Platform Team.

Case in point: Stream-aligned teams might decide to instead use their own Elasticsearch instances or third-party services, though less efficiently and with a higher cognitive load.

Let's now look at the other example.

Type 2: A Search team offers a sophisticated search service that is tailored for the specific business needs of the company, offering advanced heuristics and recommendation capabilities.

This team designs APIs that cleverly mask the complexities of the underlying engine. These APIs are tailor-made, aligning closely with the unique needs and entities of the business.

The team is regularly evaluating performances of new algorithms and models to improve search results based on some core business and product metrics.

Stream-aligned teams can integrate the Search capabilities via its APIs, and are typically allowed to iterate very quickly on how they present the information to the end user without requiring changes in the underlying Search service. Major changes to the data model across the company, such as the introduction of a completely new entity, will require coordination with the Search team.

In this case the Search team is operating as a Complicated Subsystem Team.

Why does this even matter?

One simple but very powerful reason: definition of success.

I've seen “platform” team struggling with their definition of success in many ways. Which metrics should the team optimise for? Who are their users? What type of work should they prioritise?

You don't want to have a platform team that is pulled in too many direction and becomes a bottleneck for many other teams that have a hard dependency on the services they provide.

You don't want your platform team to be in the critical path for delivering changes or improvement in the business logic exposed by Stream-aligned teams.

Conclusion

Merely offering an API to other teams doesn't qualify you as a Platform team. It's more intricate than that.

When you're confusing the two, you're not only mistaking Complicated Subsystem teams for what they aren't.

You are also promoting a rather diluted and confusing definition of what a Platform Team is supposed to be and what it should focus on.

💨 One useful smoke test to identify whether you're falling into this trap → Is any of your platform teams expected to directly influence user-facing metrics?

If that's the case, it's not a Platform team. At least not according to the Team Topologies definition, which I find to be the most useful available to date.

Truth is, you cans still decide to continue using the term Platform Team more broadly, the same way as you can call pizza something that is one inch thick and has pineapple on top.

In both scenarios, my advice would be the same: please don't!