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 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. Because the platform team is quietly building assets without anyone noticing. The solution isn't a bigger team - but by having vendors that supply capabilities organically. It's the one thing that decides whether your platform keeps evolving after launch or quietly falls 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 precisely because each one does a narrow thing properly. They are the subject matter experts, the database specialists, the terraform code gurus.

Running a market where the organizer also has to produce everything on sale and 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 actually 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. But most are run like narrowly, scoped software manfactures whom are lagging behind with their customers' needs.

The Blindspot 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 exactly this sense. But 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.

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

The inevitable bottleneck

Here is what happens when you plan for two roles instead of three: the work doesn't vanish, it lands on the platform team. Because of course it does. 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 and CI, K8S. 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 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 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. Especially onboarding comes to a halt. Why? Because the early adopters are already using it but the rest of the dev teams either don't have the skills or the time and cognitive space to figure it out. Thus 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. It's scattered because all the new capabilities are hidden in bureacratic organization of the enterprise with their multi-offices, hidden confluence pages, or from simply a lack of communication between teams. The diagnosis usually lands on adoption or funding failure when the platform with it's capabilities is simply not visualized on a central location.

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 genuinely different job from making every capability, and it's a better use of these highly skilled engineers in the organisation.
• 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 isn't headcount — it's that a single team is the sole supplier of everything. Hiring more engineers to reduce the bottleneck doesn't get rid of said bottleneck. Good as a short-term solution to lower the work load of the other engineers - yes - 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 actually be good at? Not Openshift or Terraform. No, it should be Curation — knowing what the organization needs and what the engineers wants and bringing that together.

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 ( in a timely manner).

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.