Your platform team shouldn't own every capability

Ask who a platform is for and you get a confident answer: the engineers who build it, and the developers who use it. Builders and users. This split maps neatly onto an org chart, and it is where almost every platform programme stops thinking. It's also incomplete in a way that doesn't surface for about a year, because the platform team keeps building assets without anyone noticing. A bigger team doesn't fix that. Suppliers that provide capabilities organically do, and whether you have them decides if your platform keeps evolving after launch or fades into the background while everyone insists it's fine.

A marketplace doesn't manufacture the goods

A market provides the venue and the rules. The floor, the power, the opening hours, the standards every stall has to meet, and the judgment about who gets one. It does not make what's on the shelves. That's the suppliers' job, and they're good at it because each one does a narrow thing properly. They are the subject matter experts, the database specialists, the Terraform gurus.

If the organizer also has to produce everything on sale, you don't have a market. You have a factory with a shopfront and a looong queue behind it.

The same shape holds wherever you look for it. A music venue owns the room, the sound system and the licence; the acts bring what people came for. A road authority lays the tarmac, sets the speed limits and keeps the bridges standing; delivery drivers move the goods and shoppers receive them at home. In every version, the operator who insists on also being every act on the bill puts on one mediocre show a month.

Your platform should be treated like an internal open-source community. Most are run like narrowly scoped software manufacturers that lag behind their customers' needs.

The blind spot role

Call it the supplier. For every capability your platform offers (a database, a message queue, an observability stack, a secrets store, a networking primitive) somebody has to own it end to end: provisioning, upgrades, the support burden when it misbehaves, and eventually retirement. That owner is the supplier, and the role exists whether or not anyone has been assigned to it.

The word most people reach for is vendor, which is misleading because it makes the role sound external and commercial. It often is: a managed database provider or an observability company is a supplier in this sense. The more important case is internal. Your security team publishing a hardened, self-service secrets capability, like Conjur, is a supplier. So is a data platform team offering a paved way to stand up a pipeline. They own the thing, its lifecycle, and the expertise to support it, which is the entire job description.

Whether a supplier is internal or external is a side issue. The distinction that matters is whether anyone owns the capability at all.

The inevitable bottleneck

If you plan for two roles instead of three, the work doesn't vanish. It lands on the platform team. They built the place, so they own everything in it, and each new capability arrives with an implicit "and you'll maintain this too."

The failure that follows is slow and has a recognisable shape.

• Expertise spreads thin. A team of 10 is now nominally responsible for databases, messaging, observability, secrets, networking, CI and Kubernetes. Nobody is the expert in any of it, so every capability gets maintained to roughly the depth one generalist can manage in a fortnight. It works, until the day ad-hoc support requests in Slack start catching up and the team loses control of their planned sprints.
• The roadmap collapses into a queue. Every new capability, every upgrade, every awkward edge case routes through the same team. The platform stops behaving like a product and starts behaving like the ticket desk it was built to replace, which is the failure mode an IDP is supposed to eliminate.
• Evolution stops before anyone admits it. The platform still runs. It just stops absorbing anything new. Onboarding in particular comes to a halt, because the early adopters are already using it but the rest of the dev teams lack the skills, or the time and cognitive space, to figure it out. So the golden paths age out from under the org.

None of that reads as a crisis in a status report, which is why it persists. It looks like a platform that launched well and then went quiet. It's scattered, because the new capabilities are buried in the enterprise's bureaucracy: spread over multiple offices, on hidden Confluence pages, or lost to a plain lack of communication between teams. The diagnosis usually lands on an adoption or funding failure, when the platform and its capabilities just aren't visible in one central place.

Running it as a market

The alternative is to stop running the platform as a closed service owned by one team and start running it the way a good market is run: a curated venue with many suppliers. The reframe is small but the consequences are not. In practice it means three things:

• Internal teams get a stall on the same terms as outside vendors. A published interface, a version, a named owner, a stated support expectation. Teams can quickly navigate the offered capabilities from their peers without trying to reinvent the wheel.
• The platform team curates instead of producing. Their job becomes consistency, compliance, lifecycle management and the paved road that ties the capabilities together. That is a different job from making every capability, and a better use of these highly skilled engineers.
• Developer self-service sets the roadmap. The bottlenecks, the complaints, the popular modules start to become more visible and the feedback loop becomes faster. That's a better refinement tool than any intake form with 5% response success.

The shift is from control to curation. Contributions get encouraged and supported instead of gatekept, which is the only mechanism by which a platform absorbs more than one team's worth of work per year.

Why this is a maturity question, not a staffing one

The instinct when the platform team becomes a bottleneck is to grow the platform team. It's the obvious move and it mostly doesn't work, because the constraint is a single team being the sole supplier of everything, not headcount. Hiring more engineers doesn't remove the bottleneck. It's a good short-term fix that lowers the workload of the other engineers, but platform engineering is about improving operational processes.

Suppliers are the structural fix. They also change the answer to a question most orgs get wrong: what should the platform team be good at? Not OpenShift or Terraform. It should be curation: knowing what the organization needs and what the engineers want, and bringing that together.

This is why "who supplies your capabilities?" belongs on any maturity assessment, alongside the usual questions about deployment frequency and provisioning lead time. An org where the platform team owns everything can score well on automation and still be structurally incapable of evolving its platform in a timely manner.

What it changes about build versus buy

The two-role model poisons the buying decision. If the only legitimate positions are "our team builds it" and "our developers use it," then buying anything reads as an admission that your platform team wasn't good enough. That framing kills sensible decisions for reasons that have nothing to do with economics.

With three roles, buying is ordinary. An outside supplier is a normal participant in a healthy market, not evidence of failure. The question stops being "should we have built this ourselves?" and becomes the one that matters: for this capability, who is the right supplier, and what does it cost us to be that supplier instead? Sometimes the answer is you, when the capability is differentiating. Usually it isn't, and the comparison is a curve, not a number: buying doesn't just change the total, it changes how early the value starts and how much of it you keep.

It also reframes handover. A venue you didn't build is a supplier relationship with the same shape as every other one on your platform, rather than a dependency you're stuck with.

The one-page version

Two roles is the picture everyone starts with, and it's the reason platforms stall. The platform team ends up as the sole supplier of every capability, its expertise spread across all of them, its roadmap flattened into a queue. Naming suppliers, internal or external, turns a platform from one team's output into a market.

Go and try it: list the capabilities your platform offers, and next to each one write the team that owns its lifecycle. If the same name is in every row, you've found a business process bottleneck, not a staffing problem.