An organisation chart with dates against it is two documents at once. It is a hiring plan, and it is a theory about where good decisions come from. The theory is legible in nothing more complicated than the order of arrival.
Most digital programmes give the same answer. A director is appointed. The director writes a strategy and recruits a small layer of managers to own parts of it. Only then does anyone hire the people who will build the thing. The sequence looks responsible on a slide, because it puts accountability in place before it puts spend in place. What it produces, in the first year, is documents.
A global staffing and HR services group building an integrated digital platform across national markets that had each run their own systems for years wrote its organisation down the other way round, and wrote it down explicitly enough to be checked. Five tables, one per skill family, forty-three distinct roles between them. Against each role, a single tick placing it in one of three delivery horizons. Twenty-four roles carry that tick in the first horizon, seventeen in the second, two in the third.
The interesting part is not the count. It is which roles are on which side of the line.
The challenge
Read the management and delivery table on its own. Seven roles. Four of them are ticked for the first horizon, and all four are roles that sit inside a delivery team rather than above one: product owners, service designers, agile coaches, scrum masters. The digital director and the delivery managers are ticked for the second horizon. The strategist, whose stated job is keeping the roadmap current against a moving market, is ticked for the third, and is one of only two roles anywhere in the whole design that waits that long.
The obvious objection writes itself. If nobody senior is in post, who decides what gets built. The design answers with the product owner, a first-horizon role defined as the business owner of a product who holds the concept, oversees its delivery and then runs it in operation. That is a strategy function. It has simply been distributed into the teams that will build, instead of held in a layer above them that has to be briefed, convinced and re-briefed.
Once you see the pattern in one table it is in all of them. The technology family lists eleven roles, six in the first horizon: solution architects, an infrastructure architect, software engineers, platform configurators, test and QA people, security specialists. The group enterprise architect, whose accountability is governing platform-wide technology choices, is second horizon. The data family lists ten roles, four in the first horizon, and they are the ones who touch data directly: a data engineer, a data scientist, an analytics specialist, a compliance officer. The data architect, the data manager and the data steward all wait. The creative family is the largest at twelve roles and the most front-loaded at nine, all of them production roles, with the creative director in the second horizon. The operations family has exactly one first-horizon entry, a team running continuous deployment and integration, with service management and vendor management behind it.
Five families. Five supervising roles, none of them present when their family starts work.
That is not an oversight in a table. It follows from a lesson the same document records in its own margin: hire the roles that matter early enough that they help write the strategy in detail, rather than receiving a finished one. If you believe that, the director cannot come first, because a director appointed into an empty organisation has nobody to write it with and will write it alone.
The approach
The risk in this arrangement is real and the design does not pretend otherwise. Two dozen roles start work with no management layer over them, spread across a coordinating centre and a set of country markets with very different capabilities. Something has to hold the line.
The answer is governance rather than headcount. The first horizon carries a workstream whose job is to get the decision rights agreed and operating before anything else scales, and the document is blunt about the cost of leaving it late: the moment real decisions arrive, an unagreed governance model works against you. The same first horizon is split into three shorter stages, with the opening one aimed at visible movement in every area at once rather than depth in any of them. Progress that markets can see is what buys the second horizon.
So the leadership layer is not absent. It is deferred until there is something for it to lead, and until the people it will lead have already produced the evidence that shapes what it decides.
This is the part that transfers directly, and it is where most AI programmes we are asked to review have got it backwards. The pattern is familiar: a head of AI is appointed, a strategy is commissioned, a steering committee meets monthly, and eighteen months later the organisation has a portfolio of slides and one retrieval-augmented copilot that nobody trusts because there was never an evaluation set. The roles that would have caught that, the data engineer who finds out the source systems disagree, the person who owns lineage, the analyst who builds the first evaluation set and discovers how often the answers come back wrong, are all in wave two of the hiring plan because they read as junior.
They are not junior. They are the roles that generate the facts a strategy would need to be any good. Our Consult work starts by rewriting the hiring sequence around exactly that, and the Platform work follows the same order: get data readiness, lineage and evaluation in place with the people who can actually do it, then decide what the capability should be called and who should run it.
The outcome
What this engagement produced was a blueprint. A sequenced role list, a placement decision for each role, and a recommendation to source them through upskilling, permanent hiring and contract hiring together rather than choosing one. No one was hired in this phase. The costs were named as people first and technology second, and explicitly left to be scoped rather than quantified. Nothing here is a result, and it should not be read as one.
There is one detail in the source worth keeping, because it is evidence rather than argument. In the management and delivery table, the two second-horizon entries carry written descriptions that plainly belong to other roles: one reads as a testing accountability, the other as a security one. Every first-horizon role in that table is described precisely. The layer nobody had staffed was also the layer nobody had defined, and the document shows it.
If the same design were drawn now, the family list would change and the sequencing would not. There is a compliance role in the first horizon of the data family already, which looked cautious at the time and looks like foresight since political agreement was reached on the EU's AI rules. Vector stores and grounded copilots have made the data-readiness roles more load-bearing, not less. Careful, narrowly scoped autonomous experiments are worth running early, and they are worth running by the people who will have to operate them afterwards. MLOps is the second-horizon supervising function of this decade, and it will fail in exactly the way the table predicts if it is stood up before there is anything in production to operate.
Hire the people who will do the work, and let the shape of the organisation be an argument they win rather than a diagram they inherit.