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. The split is intuitive, it 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. The missing role isn't a stakeholder to consult — it's the one that decides whether your platform keeps evolving after launch or quietly ossifies 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 precisely because each one does a narrow thing properly.

Run a market where the operator also has to produce everything on sale and you don't have a market. You have a factory with a shopfront, and a 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 actually came for. A road authority lays the tarmac, sets the speed limits and keeps the bridges standing; hauliers move the goods and shoppers receive them. In every version, the operator who insists on also being every act on the bill puts on one mediocre show a month.

Your platform is a marketplace. Most are run like factories.

The role nobody plans for

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 exactly this sense. But the more important case is internal. Your security team publishing a hardened, self-service secrets capability 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.

The distinction that matters is not internal versus external. It's whether anyone owns each capability at all.

The default is that your platform team stocks every shelf

Here is what happens when you plan for two roles instead of three: the work doesn't vanish, it lands on the platform team. Not by decision — by default. 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 six is now nominally responsible for databases, messaging, observability, secrets, networking and CI. None of them is genuinely 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 it needs to work under pressure.
• 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 precisely 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. Teams needing something it doesn't offer build around it instead of asking, and the golden paths quietly age out from under the org.

None of that reads as a crisis in a status report. That's why it persists. It presents as a platform that launched well and then went quiet, and the diagnosis usually lands on adoption or funding when the actual constraint is that one team is stocking every shelf.

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 and 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. Not a favour, not a side project, not "we'll help you set it up" — an offering with a lifecycle.
• The platform team curates instead of producing. Their job becomes consistency, compliance, lifecycle management and the paved road that ties the stalls together. That is a genuinely different job from making every capability, and it's a better use of the scarcest judgment in the organisation.
• Developer turnout sets the roadmap. The people walking the floor know which stalls are worth keeping. That's a better prioritisation signal than any intake form.

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 isn't headcount — it's that a single team is the sole supplier of everything. Adding two engineers spreads six people's expertise across nine capabilities instead of six people's across seven. The queue gets slightly shorter and the depth problem gets marginally worse.

Suppliers are the structural fix. They also change the answer to a question most orgs get wrong: what should the platform team actually be good at? Not databases. Curation — knowing what belongs on the floor, what the terms are, and which stalls to keep.

This is why "who supplies your capabilities?" belongs on any honest 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.

What it changes about build versus buy

The two-role model quietly 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 actually 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 genuinely differentiating. Usually it isn't, and the honest 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 isn't a dependency you're stuck with — it's a supplier relationship, with the same shape as every other one on your platform.

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 — is what 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 haven't found a staffing problem. You've found business process bottleneck.