Most operating model packs answer the cost question last and answer it badly, with a number that counts only the roles being created. This one answered it on a single slide with both halves visible: the whole redesign was designed to land at one or two extra people, and it lands there only because two existing roles are designed out to pay for part of it.
A global payments acquirer and processor was folding several legacy brand properties into one site and one social presence. The estate had to be run as a group asset afterwards, with shared standards, shared vendors and a governance forum that could allocate investment. The constraint sitting over the whole design was that the steering group had ruled out creating a group marketing function to do any of it. Whatever governance the estate needed had to be assembled out of business units that already had day jobs.
The challenge
The baseline is worth stating before the design, because it is the denominator that makes the final number readable. About thirteen full-time people across the whole group were deployed on specific digital activity inside the marketing and product teams, excluding support, technology and human resources. That is thirteen people for a payments business operating across multiple regions.
The distribution mattered more than the total. One business unit held eight of those roles, including the only dedicated digital content specialists and the only ring-fenced social media resource. A second held about three, one of which was a single developer who ran the entire site for that region and also handled publishing, because there was no content resource at all. The third held two, and one of those two was already writing code for another unit's site and for the corporate site as well as their own. Before anyone drew a target model, the group had an undocumented shared service consisting of one person who had not been told that is what they were.
That asymmetry is the reason the structural question was hard. Concentrating pan-group work where the capability already sits is efficient and puts the work in the unit with the most traffic and the most to lose. It also risks that unit's own campaign work being crowded out by group obligations, and it stops the other two units ever building the skills. Spreading topic ownership across units grows capability everywhere and avoids one unit dominating, at the cost of a harder job presenting one consistent story into an investment decision. Four configurations were drawn and evaluated with symmetric pros and cons: a central hub with the units as spokes, a leaderless shared model, one unit leading on behalf of the group, and subject ownership distributed across units. The central hub scored well on its own merits and was unavailable, because it required precisely the group function the steering group had ruled out.
The approach
The sequence was deliberate and it is the part worth copying. Work before people, people before structure, structure before headcount, headcount before governance, governance before approval. Each step is answerable only because the one before it is settled.
Work first meant an enumerated split rather than a principle. Every task in the estate was assigned either to the group or to a local unit, across nine domains: commercial, content development, analytics, content management, application development and maintenance, third-party management, governance, strategy and social. Two named group tasks per domain, eighteen in all, against a local column of sixteen, so the whole estate came to thirty-four named tasks. Autonomy was defined by a list, not by an adjective. The rule that emerges from the list is consistent: the group owns architecture, roadmaps, standards, shared vendors and forums, and the units own content, journeys, analysis and their own local agencies.
One line in that split does something different from the rest. Under commercial, the group is given the task of identifying and resolving lead routing issues. Every other group task is coordination, standard-setting or vendor management. That one is arbitration, and it exists because a shared site generates inbound leads that do not map cleanly to the unit that should receive them. The design anticipated the units competing over revenue and put the referee at the group level before the first argument happened.
People second meant a catalogue of eleven roles, each with a written responsibility and a classification of existing, modified or new. Six sat inside marketing and product, five sat in technology, change, communications or operational teams. Eight of the eleven were classified as existing or existing and modified. Three carried a new label, and only two of those were described as genuinely new or significantly changed. The catalogue is what converts a task split into a cost case, because only the new and modified rows carry money.
The service boundary was written down at the same level of detail: seven technology and change areas, each with a named approach and an owner, including explicit declarations of what was out of scope for the digital teams. Small development work was to sit with unit teams and anything larger to become a separately resourced project. Hosting ran on an initial twelve-month contract, and the vendor relationship was to be managed by a business team rather than by technology, which puts a marketing function in charge of a platform contract and should be recognised as a deliberate trade rather than an oversight.
The outcome
The headcount slide is short. The overall effect of the whole redesign is one or two extra full-time people depending on which configuration is chosen, and it is stated as a net effect of new roles, modified roles and roles being taken out. The footnote carries the other half: the rise of one or two is net after the removal of two existing roles, a removal this pack proposes rather than reports. So the gross creation is three or four, and the disclosed offset is two.
The slide adds a third thing that most business cases omit. There will be additional cost if roles are upgraded, with the senior digital role given as the example, and that cost is not quantified. A pack that discloses an unquantified line rather than leaving it out is a pack a board can argue with, which is the only kind worth putting in front of one.
Everything above is a design. The operating model had been presented and final approval was not yet confirmed. Roles were in place unevenly, with a mix of gaps and upskilling still required, and the plan for the period between the site launch and steady-state running was still being resourced. Nothing here is a realised headcount. It is a target with its arithmetic exposed, on its way to an executive team that had to approve it because of the people and budget implications.
The reason to publish it now is that the same arithmetic is being ducked across machine learning programmes. A feature store, a deployment pipeline, lineage that an auditor can follow, and someone who owns the standard rather than the model: those are new roles, and the business case for them is usually written as pure addition. It rarely is. Process mining and straight-through processing work delete steps, and steps are jobs. Data readiness work absorbs reporting roles that existed only to reconcile numbers by hand. The cautious language-model pilots now running in document handling will, if they work, take load off queues that are currently staffed.
Our Consult engagements ask for the net number and the gross number separately, and for the line you have not costed yet, because a programme that can only state its additions is telling the board half of a sentence. The Platform work that follows is where the deleted steps get evidenced rather than asserted, from the event logs the processes already produce.
Thirteen people, three or four new roles, two designed out, a net of one or two, and one line marked unquantified. That is what a whole estate consolidation looks like when someone is willing to write the subtraction down.