Ask a board to approve a digital platform and the picture in the room is engineers. Ask the same board to approve the organisation that the platform needs, and if the organisation has been written out honestly, the picture is wrong by a wide margin. Most of the people are not building anything. They are making things to put on it and reading what comes back off it.
A global staffing and HR services group planning an integrated platform across its national markets wrote the organisation out in full, five tables, one per skill family, a row per role. Counting the rows gives forty-three distinct roles: twelve creative, eleven technology, ten data, seven management and delivery, three operations. Creative and data together stand at twenty-two against technology's eleven, which is two to one on the nose.
That ratio is not a rounding artefact of how someone drew the tables. It is what an integrated platform costs in people once you stop describing it as a build and start describing it as a thing that runs.
The challenge
The counting needs one piece of care: the technology table enters the same architect role twice, identical description and identical horizon mark, so its twelve rows resolve to eleven roles. Every other row appears once, and the totals close on forty-three.
The family labels then turn out to be the least reliable thing on the page. Read each role by what its own description says it does, and the build population scatters. Six technology roles write or configure the running system: back-end software, platform configuration, interfaces, mobile applications, web services, infrastructure. But the role responsible for the technical development of the interface sits in the creative table. The role creating data flows and queries to join disparate sets and extract features sits in the data table, alongside the one maintaining the technical side of the data environment. The role executing continuous deployment and integration sits alone in operations.
Add those up and ten roles of forty-three write or run software. Six of the ten are in the family called technology. The other four are filed under creative, data and operations, because that is where the work belongs, not because anyone was being loose with a label.
The remaining five technology roles are not building either. Three are architects, one owns quality assurance and test plans, one owns security standards. Those are judgement and governance roles wearing a technology badge. Strip them out and the org chart for a digital platform is roughly a quarter builders, and three quarters people who decide what to build, make what goes on it, or interpret what it produces.
The approach
The shape follows directly from the architecture, which is the part worth carrying into any similar decision.
Three platform options were evaluated against five design principles. Separate implementations per market, one consolidated global system, or an integrated platform that lifts the customer-facing and candidate-facing systems off the back office and layers experience, automated workflow and data over the top through an integration layer. The third was recommended. The back-office estate, contracting, payroll, invoicing, finance and HR, stays where it is. The layer above it is what gets consolidated.
Once that is the architecture, the ratio stops being surprising. A platform whose value sits in the touchpoint needs people who make touchpoints. A platform promising straight-through processing on the volume end needs people who define what the workflow may do without a person in it. A platform treating data as the thing driving the business needs ten data roles, of which only two are engineering ones.
The second signal in the tables is sharper than the headcount and easier to miss. Each role is marked as operational work, project work, or both. Nine roles across the whole set are marked project only: five technology, four management and delivery. Not one creative role is project only. Not one data role is. Not one operations role is. Every job here scoped to end when the build ends is a technology or a delivery job.
That is the sentence that should have priced the programme. A build has an end date and a contractor rate. An editorial function, an analytics function and a data stewardship function have neither. Four sourcing routes were assessed against the same five principles and three were recommended in parallel: retrain, hire permanently, hire on contract. Outsourcing was set aside for a reason worth repeating, that it does not bring the key skills in house and the data leaves the organisation and may not come back. Contract hiring maps cleanly onto the nine roles that finish. It maps badly onto the thirty-four that do not.
A third column set says the same thing again. Each role is placed against three market sizes: central, large local, small local. Every technology, operations and delivery role reads no in the small markets. Ten roles are marked yes or possibly in the small markets, eight creative and two data, and the two data ones are compliance and stewardship, present where the rules differ rather than where the volume is. Two roles in the entire forty-three do not exist centrally, and both are creative, sitting only where a market talks to its own audience.
The platform is central and the voice is local, which is a governance model expressed as a staffing table rather than a policy document.
The outcome
What this phase produced is a blueprint: a recommended platform direction, an organisation written out role by role with market coverage and delivery sequence against each one, and a sourcing approach. Nobody was hired inside it and nothing was built. Every number here is a count of rows in a plan, not a measurement of an organisation that exists.
Three things would be done differently now, all from the same observation, that the tables describe a running cost nobody had a way to see.
The ten data roles are, read plainly, the operating cost of putting models into production without a platform underneath them. A data engineer creating flows to join sets and extract features is describing a feature store nobody had. A statistician assuring the quality of derived models at delivery and over their lifetime is describing model monitoring done by hand. A steward maintaining common definitions of data elements is describing lineage kept in a document. The right question at blueprint time is not how many data people the platform needs, it is how much of what those people are being hired to remember the machine learning pipelines could record instead.
The workflow layer deserved a measurement rather than a diagram. Straight-through processing was the commercial promise on the volume side, and the blueprint asserts it as a design rather than sizing it. Process mining over the existing case events would have shown which paths already complete without a person and where the handoffs sit, which changes both the automation scope and the operations headcount behind it. The Platform work we do starts there now, because the layer the whole role plan balances on should not be specified without event data.
And the creative twelve deserve a second look for a reason nobody in that room could have had. The cautious language-model pilots we run with clients in copywriting and editorial work do not remove those roles. They change the mix inside a role that never ends: less first-draft production, more judgement, more checking. That is an argument for retraining the people already in place, which the blueprint itself named as a lesson worth not overlooking, and it is the kind of shift our Consult engagements now size before a hiring plan is signed rather than after.
The finding carries into any industry unchanged. When an organisation writes out who a platform needs and the answer is mostly not engineers, the plan is not confused. It is telling you the platform was never the product.