An organisation counts its people when it wants to know what it can afford. It should count them when it wants to know what it can promise. A global payments acquirer and processor did the first, honestly and in public, and the number it produced was small enough that the second question answered itself, if anyone had asked it.
The baseline said there were about thirteen full-time equivalents deployed on specific digital activity inside the marketing and product teams. That figure excludes internal IT, HR, support functions and an acquired business carrying a further three to four people, and the exclusions are printed on the slide rather than hidden in a note. Thirteen was the working number for the group.
The challenge
Thirteen is not the finding. The distribution is. Eight of those roles sat in one business unit. About three sat in another, of which one was a developer and two were digital-specific staff. Two sat in the third. Read that as a capability map rather than a payroll line and the picture sharpens: one unit held more than half the skill in the group, one unit ran its whole regional site on a single developer, and two of the three units had no dedicated digital content resource at all. In one of them, publishing was done by the developer. In another, the single web producer was also writing code for two other properties, which made one person a cross-unit dependency before any consolidation had begun.
Third-party ownership showed the same drift. Hosting for one regional site was managed by the developer who worked on it. Search marketing was managed by the person who published content. Nobody had assigned those relationships. They had settled on whoever last touched the tool.
The estate was about to change underneath all of this. A spread of legacy brand and product properties was folding into one corporate site, and four shared substrates arrived at once: a common content management platform, common analytics, a common hosting partner and a common customer record. That is the technical event that forces the organisational one. Once three business units share a content platform and an analytics stack, no unit can ship a change without touching a surface someone else owns, and decision rights have to become shared whether or not anyone designs for it.
The constraint on that design was written down before the work started. The steering group had ruled out any group marketing function. Pan-group governance therefore had to be assembled out of the three existing units, with no central team to assemble it into. Every option that followed was an attempt to manufacture coordination without headcount.
The approach
The sequence was disciplined and worth copying. Scope first: a fixed capability list grouped under four pillars covering strategy and direction, application development and maintenance, measurement and monitoring, and vendor management. Fixing the list before the ownership argument gave every later artefact the same denominator, so the task split, the role catalogue and the headcount case could not quietly change subject.
Then the task split, which is the most reusable thing in the pack. Nine domains, and inside each one an enumerated list of pan-group tasks and an enumerated list of local ones. Two named pan-group tasks in every domain, eighteen in total, with the local column set out beside them. Autonomy stops being a principle at that point and becomes a list. The rule underneath the list is clean: the group owns architecture, roadmaps, standards, shared vendors and forums, and the unit owns content, customer journeys, local analysis and local agencies. One line breaks the pattern. Resolving lead routing issues was assigned to the group, and it is the only task in the split that assumes the units will actively compete rather than merely overlap. A shared site produces enquiries that no longer arrive pre-labelled with an owner.
Then eleven roles, each classified existing, modified or new. Three carried a new-or-modified label, and not one of the eleven was marked new outright. The other eight were existing, or existing and modified. Six sat inside marketing and product; five sat outside it, in change, IT, HR and communications. The honest reading is that the capability mostly existed and the contracts with it did not. The role invented to hold the whole thing together was given three accountabilities in the catalogue and no reporting line beside them, and the pack's own risk language names the consequence twice: a model with no lead means the loudest voice wins, and a distributed one requires more influencing skill from the digital lead.
Four configurations were then drawn against that role set, and the most instructive detail is which one lost. The centralised hub is the only option whose pros are all governance goods: impartial governance, strategy and standards held centrally, and centralised tasks that avoid duplication. The first entry in its list of cons is not a weakness in the design at all. It records a decision already taken elsewhere, that no group marketing function was planned. Operating models are chosen inside political constraints, not on merit, and a design that pretends otherwise wastes a cycle proving what is already ruled out.
The cost answer landed at a net increase of one or two people. That figure is net after two existing roles were removed in the unit that held eight, so the gross new role creation is three or four. Grade inflation on upgraded roles was acknowledged and not quantified, and the pack says so rather than burying it.
The outcome
What this engagement produced was a pack, version two, revised after a steering group had already pushed back on version one. Sign-off was scheduled, not recorded. The design cycle ran about ten weeks on the timetable, from a data refresh through stakeholder interviews to a scheduled sign-off, and the title of the timetable slide concedes the model may still contain transitional elements at the point of approval. A transitional period was scoped at roughly three to four months from launch, carrying eleven workstreams and the creation of three governance forums, while the permanent model remained unapproved. Two of the delivery partners, between them supplying digital leadership, programme management, technical leadership, design and build, were scheduled to finish on launch day, one of them with a short contracted mop-up sprint after it. Nothing in the source says the structure was implemented, and nothing here should be read as saying it was.
The honest question is what would be done differently if the same baseline ran now. Three things.
The count was assembled by hand, from interviews, so it is a snapshot of who was in the room. The tasks in that nine-domain split are almost all observable. Publishing approvals, content workflow states, prioritisation queues, helpdesk triage routes and analytics requests all leave events behind them. Process mining over those events produces the same split with a source attached, and it answers the question the pack never asks: how much of each named task is actually being done, and by whom, versus how much is aspiration written into a column. That event trail is the first thing our Platform work instruments, because a task split you can check beats a task split you have to believe.
Second, several of the enumerated tasks are candidates for straight-through processing rather than staffing. Simple content changes inside published guidelines, standard reporting against common templates and first-line query routing are all rule-bound work sitting in front of a person because no one has instrumented the path. Adding one or two people to thirteen is a decision about supply. Reducing the number of tasks that require a person is a decision about demand, and only one of those two was on the table.
Third, the early and cautious language-model pilots now appearing in content drafting change none of the arithmetic on their own. A model that drafts a page well still needs a workflow to put the draft into, a sign-off route inside the published standards, and a lineage trail showing what was generated, by whom it was approved and against which version of the guidelines. Where that path is not instrumented, the draft lands in a queue and the pilot is a demonstration. Our Consult engagements start by measuring that landing point, because it is the cheapest way to separate an interesting pilot from work that will pay.
Thirteen people was never a team size. It was a measurement of the estate the group had before consolidation, carried forward unexamined into the estate it was about to build. The redesign around it was careful, countable and honest about its own costs. It simply took the number as given.