The Platform Responsibility Line

A platform that owns too little is ignored. A platform that owns too much becomes the bottleneck it was built to remove.

In one sentence: a platform owns what must be the same for everyone, and nothing that must be different.

The problem

Every internal platform team eventually has the same argument, usually without naming it: what is the platform responsible for, and what is the consuming team responsible for?

Get the line wrong in one direction and the platform is a thin wrapper nobody values, because every team still solves the hard parts themselves and solves them differently. Get it wrong in the other and the platform becomes a queue. Everything routes through five people, and the platform is now the constraint it was funded to remove.

The line is usually never drawn explicitly. It is inferred from whatever the platform team said yes to last quarter, which means it drifts steadily toward owning more, because saying yes is easier in the moment.

The model

Test one: same or different?

Things that must be the same across every team are platform responsibilities. Identity, access, audit trails, environment provisioning, deployment mechanics, monitoring primitives, cost attribution, the promotion path. Divergence here produces risk and duplicated effort with no upside.

Things that must be different per team are consumer responsibilities. Model choice, feature engineering, business logic, evaluation criteria, the definition of good enough. Standardising these is how a platform team ends up doing data science badly on behalf of people who do it well.

Test two, for the middle: between the two sits the interesting category. Pipeline orchestration, feature stores, experiment tracking, testing approaches. For these, ask:

Would standardising this remove work from teams, or remove choices from them?

Remove work, and it belongs to the platform. Remove choices, and it belongs to the consumer, or to the platform as an optional default that teams may decline. The optional default is underused and is usually the right answer.

How to use it

List every capability in play, honestly, including the ones currently handled by one helpful person. Sort each into same, different, or could-be-either. Apply the second test to the middle pile.

Then publish the line and treat changes to it as a decision with a record, not as an accumulation of favours. The publishing is most of the value. The argument was always going to happen, and it is far cheaper as a design conversation than as a resourcing crisis.

Revisit when the consumer count changes materially. The right line for four teams is not the right line for fifteen.

When to use it

When the platform team is quietly absorbing work nobody funded, when consumers are frustrated that the platform "does not do enough", when a new capability request arrives and nobody can say whether it belongs, or when planning a platform's second year.

Limitations

This is a model for steady state, not for a new platform. Early on, a platform team should do more than the line suggests, because the alternative is no adoption. The model tells you what to hand back later, and handing back is harder than it sounds, because teams reasonably come to expect the service.

It says nothing about how well anything is built. A correctly drawn line around poor capabilities is still a platform nobody wants to use.

It assumes reasonably comparable consumers. Where one team has genuinely different needs, the honest answer is sometimes that they should not be on the platform, which is a conclusion platform owners are institutionally reluctant to reach.

And it is a design tool, not a negotiation. It will not settle an argument where the real disagreement is about headcount.

An example

A shared machine learning platform is asked to take on model monitoring. It sounds like an obvious platform responsibility, and half of it is.

Applying the test splits it cleanly. That monitoring exists, that it emits alerts, that outputs are retained for audit, that operational metrics are collected: these must be the same for every workload and belong to the platform. What counts as drift for a specific model, what threshold matters, what the business impact of degradation is: these must be different per team and belong to the consumer.

The platform provides the capability and the defaults. The team owns what good looks like for their model. Neither side is doing the other's job, and the argument does not need to be had again next quarter.

Why this matters in a hiring conversation

It is the clearest available demonstration of platform product thinking as distinct from delivery management: the unit of value is the tenth consumer, not the current one.