You Don’t Need a Bigger Platform Team, You Need a More Collaborative One

As organisations scale, platform teams often face mounting pressure to support a growing number of tools, services, and workflows. The instinctive response is to hire more engineers, but this quickly becomes unsustainable, both financially and operationally. 

The reality is that complexity in platform engineering doesn’t always need brute force; it needs distributed expertise and smarter collaboration.

There’s growing recognition across the industry that internal platforms must evolve beyond centralised models. Terms like “Platform as a Product” and “X-as-a-service” are everywhere, yet many companies still centralise all platform responsibilities in a single team. This results in cognitive overload, bottlenecks, and missed opportunities to tap into institutional knowledge.

This article reframes the discussion from “headcount” to “collaboration.” Reiterating Paula Kennedy’s talk “How Platform Engineering Really Scales DevOps”, it advocates for a multiplayer approach where specialised teams across the business can contribute their knowledge to the platform without increasing the platform team size.

How we got here: From DevOps to platform overload

DevOps didn’t come out of nowhere. It originated from the Agile methodology, change management principles, and other processes that can be traced back decades. DevOps emerged as a solution to the collaboration challenges organisations faced, introducing tools and processes that enable seamless collaboration between Development (Dev) and Operations (Ops). 

DevOps works, and works well. But as we have seen at scale, it has its own challenges on both sides. On one side of the spectrum, multiple DevOps teams struggle with repetitive problems and an increased workload. 

And on the other side, the “you build it, you run it” approach has its challenges. Some people say it is the ultimate frictionless developer enablement or experience, while others would argue that this is just a way for operations to turn off their pagers and put developers on call instead.

To address these growing DevOps challenges, platform engineering has emerged with a primary focus on delivering a better developer experience. One that reduces developer cognitive load by delivering value to customers and streamlining the operations that support it. 

The platform engineering process

However, just like DevOps, platform engineering has evolved into a catch-all term for various practices and tools, sometimes straying from its original cultural roots. We now see terms like “You own the platform, you build it”.

The cognitive load has just been transferred to platform teams, tasked with providing a customised internal developer platform (IDP) that meets developer needs and offers tooling and services on demand.

 Increased cognitive load in platform engineering

Now the question is, how can platform teams scale their platforms without the added cognitive load?

Platform teams were not meant to know everything

In most organisations that have an IDP, it's not just the platform and development teams that are part of the entire engineering function. There are other specialist teams, such as the database team, compliance/legal team, or networking team. 

Imagine a new experienced engineer, named "Stephanie," joins the platform team to help implement a MySQL platform offering. Of course, she knows and uses MySQL, but does she understand MySQL enough in your organisation, with the same context as “Jane,” who has been in the database team for 2 years? No, she doesn’t. And for Stephanie to replicate that context. It will require more cognitive effort.

What if Jane from the database team could collaborate with Stephanie to build out that platform feature?

This is where the multiplayer approach comes in. 

Introducing the multiplayer model (shared contribution)

With the multiplayer model, the platform team owns the platform, but doesn’t build it alone. Going from DevOps, platform engineering scales DevOps, and the multiplayer model scales platform engineering. 

The multiplayer model is sometimes called platform democratisation or producer/consumer model, where the producers are the platform team in collaboration with other teams, and consumers are the developers. 

With this model, Jane can integrate all the database requirements into a platform building block and contribute it to the platform, so the platform team doesn’t have to learn all that is required to meet your organisation's requirements for MySQL. The same applies to other specialist teams, such as security, networking, and observability. 

If you can take specialist tools that experts in your organisation know precisely how to utilise, turn them into building blocks and integrate them into the platform, then you’re not passing over knowledge to the platform; you're just passing over the capabilities. 

Through this producer and consumer approach, you end up with multiple people contributing to the platform with growing capabilities that are not coming at the expense of the platform team's sanity and mental health. 

The multiplayer mode architecture

The multiplayer model in practice

If you were thinking, how could you put this into practice? Then, that’s a valid question.

If you were also thinking that this could only be done with a Greenfield (new) platform, then well, you’re not so correct. You see, all platforms are Brownfield (legacy) because the processes, tools, and practices that get built into them already exist.

To implement the producer/consumer model, you need to build/improve your platform in a way that enables specialist teams to use the tools they already use, rather than forcing them to adopt or integrate into a pre-packaged solution. 

One way to achieve this is by utilising an open-source platform orchestrator like Kratix. At the core of Kratix are Promises, and these are a set of instructions written in YAML that produce a resource whenever they are invoked.

Each Promise consists of:

• API description of how a user can request that Promise.

• Dependencies, which are optional and can be made a requirement, before a developer can request the Promise. 

• Workflows that define how provisioning takes place. 

• Destination rules that allow the Promise Author (Producers) to determine where resources should go.

A Kratix Promise

A Promise can also be a dependency in another Promise, forming a compound promise that builds on existing building blocks. 

With this approach, you can run software-as-a-service on your platform, leveraging institutional knowledge.

Let's consider a platform team example where they want to collaborate with the observability team to offer a Prometheus service to developers via the platform.

They can work with the observability team to create a base Promise promoperator that deploys the Prometheus Operator cluster-wide, enabling CRD-based management of monitoring resources, as shown in the example below. 

Now that the foundation is set, the platform team can create an AppObservability Promise that enables development teams to request isolated Prometheus instances and monitoring configurations, such as PodMonitors, through a self-service API or UI with Backstage.

Note: For reference purposes, code samples were trimmed.

This creates a foundation for the platform team to build several features based on the promoperator that satisfy the requirements of the observability team and enable developers to get their job done. 

We discussed and demoed this use case in-depth in the article: Creating a Multi-Tenant Prometheus Service with Kratix. In it, you’ll see precisely how to transform Prometheus from a growing operational challenge into a seamless internal platform feature, ready for your organisation’s next stage of growth.

Don’t reinvent the (platform) wheel

Institutional knowledge about platform services and tools already exists in your organisation. There is no need to spend time and resources recreating what already exists.  

Implementing a multiplayer approach where specialised teams can contribute to the platform benefits not only the development and platform teams but also the entire organisation, as everyone collaborates towards the same goals more effectively.