Consolidating six websites onto one is a delivery project with a date on it. Deciding who is allowed to change the shared parts afterwards is a reorganisation, and it tends to arrive with no sponsor, no budget and no name.
A global payments acquirer and processor had grown by acquisition and was carrying the residue: six legacy brand and product web properties, plus per-unit sites, campaign pages, servicing portals and a careers site, built and instrumented separately and hosted in different places by different people. The target state folds the brand properties onto a single corporate site and introduces four shared substrates at the same moment: a common content management system, common analytics, a common hosting partner and a common CRM.
The estate map carrying this was drawn as a technology diagram. Read it as an organisation chart instead and it says what the technology framing never claims: once the arrows land, six properties depend on four platforms none of them controls alone.
The challenge
The constraint had been settled before any design work began: the steering group agreed there would be no group marketing function. Whatever pan-group direction, standards and prioritisation the shared estate needed had to come out of the three business units that already existed. A standards and guidelines layer appeared in the target state, sitting over the shared platform, with no box on the chart to hold whoever would write it.
Stakeholder interviews recorded the tension rather than resolving it. Units had benefited from autonomy in running their own web presences, accepted that a shared site needs shared rules, and wanted to concede as little as possible. Commercial ownership of journeys was to stay local, while the parts every journey runs through, the site structure and the filtering rules, needed consensus before anyone changed them.
Stated at that altitude the problem has no answer. What made it tractable was refusing to argue it as a principle. The design defined autonomy by enumeration: nine task domains, each with a named list of what the group does and a named list of what a unit does, at two tasks a side.
Line the four shared substrates up against that list and the pattern is not gradual.
Content management keeps two tasks on each side. The group owns the platform roadmap and the content workflow process; a unit updates its own pages within the guidelines and runs the sign-off process for its own content. Analytics reads the same way: best practice, the measurement approach and overall site performance with the group, journey analysis on a unit's own traffic and federated tool access with the unit.
Hosting does not read that way. Both of its named tasks are pan-group, the hosting provider and the platform vendor along with the interface into the internal helpdesk, and no local task is written against it anywhere in the nine domains. The service management table then placed the hosting vendor relationship with a business unit team rather than with IT, which makes a marketing function accountable for a platform contract on an initial term of twelve months.
The CRM is the sharpest case, because it does not appear in the task split at all. It sits in the target-state architecture as one of the four things every property is to share, and in the scope taxonomy under maintenance. Then it has no row: the service management table hands the CRM and the learning system to a central technical function reachable only by raising a work request, and puts the servicing portals out of scope for the digital teams entirely. A substrate shared by six properties, with no owner named anywhere inside the operating model written to run them.
The approach
The shape in the exhibit is the finding. Independent footings fall away as the substrate is shared more completely, and on none of the four planes is a surviving footing a brand-level one. The brands go first. What follows is a negotiation between three units and a centre ruled out of existence.
Two design moves followed. The first was to write the split as tasks rather than as ownership. A unit told it owns content stops at the first shared template and starts an argument. A unit handed four things it does and two it does not can plan around the boundary, which is a smaller and more honest promise.
The second was to make governance dual-sided. The group runs the forums and the prioritisation process; the unit holds a seat on the forum and an input into prioritisation. Autonomy you cannot exercise where the queue gets ordered is not autonomy, and a shared platform turns almost every question into a queue.
The tell that the design took the conflict seriously is one line in the commercial domain. Of the eighteen pan-group tasks named across the nine domains, seventeen are coordination work: roadmaps, standards, shared vendors, forums. One is not. Identifying and resolving lead routing issues is dispute resolution, there because a shared site generates inbound leads that do not map cleanly to the unit that should receive them. The group holds the investment coordination and the disputed leads. The unit holds the conversion.
This reads as a live problem rather than a historical one because the substrates changed and the arithmetic did not. Swap the four in this pack for the four most data organisations are standing up now: a feature store, a model deployment path, a lineage and data-readiness layer, and one analytics warehouse under all three. The first team to publish a feature into a shared store has decided on behalf of every team that later reads it, and the first model promoted through a shared deployment path sets the review standard for everything queued behind it. MLOps conversations treat these as engineering choices because engineers are who is in the room, and the consequence surfaces two quarters later as a backlog nobody agreed to.
The Platform work we do starts from the same enumeration this estate pack used. Which decisions on the shared substrate stay with the team, which move to the centre, and which have no owner named at all. The third list is worth finding early; here it had one entry, and that entry was a CRM six properties depended on. Process mining is what turns the list from an assertion into a measurement, because the workflow events say who actually approved a change, how long it waited, and how often the shared queue was the binding constraint.
The outcome
What this engagement produced is a design pack, not a running organisation, and the tense matters. The task split, a catalogue of eleven roles classified as existing, modified or new, four candidate configurations, and a transition plan with resourcing options against each activity, all taken to the steering group. Sign-off was routed onward to the executive team, because the recommendation carried people and budget implications the steering group could not settle alone. The headcount effect proposed was a net increase of one or two full-time equivalents, itself a net figure after two existing roles came out of one unit, and the numbers behind that chart sit inside an image on the slide. None of that says the model was adopted, only that it was designed, costed, and put in front of the people who could authorise it.
The part worth carrying is smaller than the pack and older than anything technical in it. Shared infrastructure is a decision-rights change wearing a platform costume. It gets presented as a saving, a consolidation or a migration, and approved on those grounds, because they are legible to a finance committee in a way that "who is allowed to say no" is not. The second question still has to be answered, and the only real choice is whether that happens before the platform goes live or after.
The early and cautious language-model pilots now appearing in content and support work make ignoring it more expensive. A pilot that reads a document well still has to write its answer into a shared system, on a schedule somebody owns. Where nobody owns it, the pilot finishes as a demonstration.