Scope Before You Argue About Owners

Almost every language model programme I am asked to look at this year arrives with an ownership question already in the room, and almost none arrive with a list.

Who owns the assistant, the central data team or the business whose documents it reads. Who owns the evaluation set, the people who built the thing or the people whose judgment it grades. Who owns the refusal behaviour, risk or engineering. Who holds the vendor relationship when pricing changes or a version is retired. The debate runs hot for a few weeks, a structure gets drawn, and two quarters later the same questions come back untouched, because the boxes were drawn over work nobody had written down.

I keep going back to an operating model and organisation design I worked on for a global payments acquirer and processor, long before any of this vocabulary existed. The technology there says nothing to the present case. The sequencing says everything.

The conditions that guarantee an ownership fight

Three business units were folding separately acquired propositions under one brand, which meant one public site and one combined social presence where there had been several of each. The steering group had already ruled out any group-level marketing function. So the shared work still had to be done, and every pair of hands available to do it reported into a unit with its own commercial targets.

The stakeholder interviews recorded what you would expect. Strong acceptance that the units now had to work together. Equal attachment to the autonomy and the absence of bureaucracy each had enjoyed while running its own site. Explicit discomfort with putting too much responsibility into any one unit. A firm view that each unit had to keep control of its own commercial journeys through to fulfilment, alongside recognition that some parts of the site were common fabric and could not be changed unilaterally.

Read those positions and you can predict the meeting. Everyone is right, everyone is defending something real, and there is no shared object to be right about.

What got written down first

Not a structure. The work.

The pack opened on the kinds of activity the shared estate would require, laid out on one surface, from the strategic end down to the parts nobody puts on a slide: publishing content against an agreed process, managing the addresses pages live at, parsing an incoming query to whoever can answer it. It went to the steering group as an inventory before it went anywhere as an organisation.

Against that inventory the pack laid the current state of all three units, side by side, in the same categories: who does this today, with what dedicated resource, and where it goes outside. That baseline came to roughly thirteen people on digital-specific activity across the three marketing and product teams, unevenly spread, with one unit carrying most of the capability and another running on a single developer.

Only after those two pages did the argument start, and by then it had a shape that could be settled. Each item was assigned as shared or local one at a time, rather than by handing whole functions to whole units. Eleven roles were derived from the split, six in marketing and product and five in communications, IT or unit operations. Three carried the word new, each hedged as new or modified, which is a polite way of saying the work already existed and the job description did not.

Four ways of configuring those roles were compared, and the pros and cons of each were about the distribution of the same list of work: whether leadership sat in one unit or spread across units by topic, what each bought in consistency, what it cost in autonomy or duplicated skills. Headcount arrived at the end as arithmetic rather than negotiation, a projected net one or two extra full-time roles once two existing roles in one unit come out, with a note that some cost would come from upgrading a role rather than adding one.

The agenda for the decisive working session followed the order the pack was built in. Tasks, then roles, then the options for configuring those roles, then a walkthrough of how each option handles real changes to the site, then headcount, then transitional arrangements and governance forums, then sign-off.

Why the denominator matters more than the answer

Once the inventory exists, the ownership question becomes checkable. Is every item owned. Is any item owned twice. Does anyone recognise the item they have been handed. Those have answers, and all four structures could be tested against them by the same method.

Without it, each party describes the work in whatever shape supports its claim on it. The unit with the most traffic describes the estate as mostly campaign execution. The unit with the developer describes it as mostly build. Both are honest, neither is complete, and the meeting resolves in favour of whoever speaks last or reports highest. An ownership argument held before the work is written down is not a hard question. It is an undefined one. Producing that list is the opening block of a RealAI Platform engagement, which is why we ask what there is to own before who owns it.

The same move, one technology later

The equivalent inventory for a programme building retrieval-augmented assistants and copilots is not hard to write. It is rarely written, because the thing gets discussed as one lump called the assistant.

Retrieval is one item: which corpus, kept current by whom, with what lineage back to a system of record, and who decides when a document is authoritative. The vector store is another: who refreshes it, who is accountable when an answer cites something withdrawn a month ago. The evaluation set is a third, and the most contested, because the people who can write the questions are the people whose day job the assistant touches, not the people who built it. Then the refusal and guardrail policy. Then tool and system access, meaning what the assistant may read and, in the early and carefully scoped autonomous experiments some programmes are now running, what it may do. Then the escalation path to a human, who staffs it and at what response time. Then vendor management: versions, deprecations, pricing changes, data handling terms.

Eight items, and most programmes I see have owners named for two. That is not a governance failure yet. It becomes one at the first incident, when the question of who owns the wrong answer is asked for the first time and answered by whoever is in the room.

Three things transfer from the older engagement. The first is that most of the work lands on people who already exist under modified descriptions, not on a new function. A catalogue where only three of eleven entries carry the word new is the normal outcome of scoping honestly, and the outcome a central AI team rarely wants to hear. The second is that a capability can be bought rather than staffed, but buying it is itself a capability with a named manager: hosting sat with an external provider on a fixed contract term, first-line support was defined as parsing queries onward rather than resolving them, larger development was treated as a separately resourced project. In each case the design said who manages the supplier. Model vendor management deserves that treatment now and almost never gets it.

The third is that alternatives only become comparable after the list exists. Central platform team against federated ownership is the same argument as concentrated against distributed leadership: unresolvable in the abstract, tractable once you are distributing named items.

~13

People on digital-specific activity across three units, current-state baseline

11

Roles in the pack's proposed catalogue, six in marketing and product

3 of 11

Roles carrying the word new, each hedged as new or modified

+1 to +2

Net full-time roles the pack projected, once two existing roles come out

The timing argument

There is a reason to do this now rather than after the next pilot. The European AI regulation has reached political agreement, and the supervisory questions it points at are ownership questions: who maintains the evaluation evidence, who keeps the logs, who exercises human oversight, who signs off a change. An inventory with names against it answers those. An organisation chart does not, because a chart records reporting lines and the questions are about activities.

Data readiness sits the same way. Lineage is not a property of a model. It is a property of a corpus somebody maintains, and maintenance is an item on a list or it is nobody's job.

An ownership argument held before the work is written down is not a hard question. It is an undefined one, and undefined questions are settled by whoever is most senior in the room rather than by anything that can be checked afterwards.

What this was, and what it was not

That pack made recommendations. It scheduled a sign-off, to be agreed at the steering group and then carried upward because of the people and budget implications, and it proposed transitional arrangements around the new site going live. I make no claim about what was approved.

The part worth taking had already paid off before any decision was made. By the time the units argued about who should lead, they were arguing about a fixed set of named activities, with a baseline underneath and a headcount consequence that could be calculated rather than feared. That is the whole trick, and it costs a few weeks of unglamorous listing work.

Drawn from an operating model and organisation design pack for a global payments acquirer and processor: its current-state capability baseline, its split of shared against local activity, its role catalogue, its four structural options and its headcount note. That pack produced findings and recommendations ahead of a scheduled sign-off, not delivered results. The reading of it as a lesson for language model programmes is ours.