Most data organisations are assembled in an order that looks obvious from the inside. Engineers first, because there are pipelines to build. Scientists next, because there is a model somebody has promised. Then, once the model is scoring live records and a client or a regulator asks a question nobody can answer from the logs, a compliance role gets created. By that point the platform already has a shape, and the only instrument the new role holds is refusal.
A global staffing and HR services group, planning a shared data capability that would run across national markets with different systems and different rules, wrote the sequence down the other way. Its blueprint defined ten data roles and placed each one against three market sizes and three delivery horizons. Four roles were marked as required in the first horizon: a data engineer, a data scientist, a digital analytics specialist, and a data compliance officer. The other six waited.
The challenge
The business this platform was meant to serve runs on records about people. Candidates, skills, availability, placement histories, the outcome of every introduction. The commercial ambition attached to that data was better job matching, with straight-through processing on the volume end so a request could complete without a person touching it. The engineering ambition was ordinary for its moment: join disparate data sets, extract features from them, and put a model where a human judgement used to sit.
The organisational question was harder than either. The group operated national markets of very different sizes and maturity, each carrying its own legacy estate, and a shared capability built centrally has to decide, role by role, what lives in the centre and what lives in a market. So the role table was written with three columns for that decision: central, large local, small local. Every role in the family carries an entry in each column, and the entries are not uniform. Some roles read "yes, execution" in the large markets and "no" in the small ones. Some read "unlikely" in the large markets and "no" in the small ones.
That is the part worth slowing down on, because a role table with three market columns is not an org chart. It is a set of rules about when a market earns a person.
The approach
Read the ten roles down the small-market column. Seven say no. An eighth, the data scientist, says unlikely. Two say yes, and only one of those two says yes with a condition attached. The data compliance officer is scoped as central for oversight, local execution in the large markets, and present in the smallest markets where regulations differ. The other yes, the data steward, is written in flat: present as a role, no condition, no test.
That is a conditional written into an organisation design. The trigger for putting a compliance person into a small market is not headcount, revenue, or how much data that market generates. It is whether that market's rules disagree with the ones the centre is already working to. No other entry in that column carries a test at all. The other nine are flat answers about whether the work justifies a person, and this one is an answer about whether the rulebook does.
Putting that role in the first four, alongside the engineer and the scientist, is a claim about what the platform is allowed to become. A compliance officer who arrives in the first horizon is in the room while the pipelines are specified, which is the only moment when retention, purpose limitation and consent are cheap to build. A compliance officer who arrives in the third reviews what already runs. The work is nominally the same and the power to change anything is not.
One honest wrinkle sits in the source and is worth reporting rather than smoothing. The short description written against the data compliance officer is word for word the description written against the data steward: create and maintain a common set of definitions for data elements and entities. It reads either as a duplication in the pack, or as a deliberate statement that compliance begins as definitional work. Both readings are available and the slide does not settle it. What the slide does settle is the sequencing, and under either reading the sequencing is the same: the steward, whose whole job is those definitions, sits in the second horizon. In the first wave, the person nearest to the definitional question is the compliance role.
Which leads to the other half of the table, and it is less flattering. The six deferred roles are the data architect, the data manager, the data platform engineer, the data steward, the data visualiser and the statistician. The steward is where the two halves of the table disagree: it is the one role besides compliance that the small-market column places in the smallest markets, and the sequencing columns still make it wait a horizon. Strip the labels and what has been deferred is the layer that decides what the data means and how the environment holding it is designed. The first horizon staffs the people who build and the person who says what may be built with. The people who define terms and own the architecture follow a horizon later, by which point there are pipelines and models running on definitions nobody has yet been paid to write down.
The statistician entry carries the sharpest version of that. Its remit is stated as assuring the quality of derived models at delivery and during their lifetime. Somebody had already worked out that a model degrades after launch and that degradation needs a named owner rather than a shared intention. Then that role was placed in the second horizon, behind the models it was meant to watch.
The outcome
What this engagement produced is a blueprint. Ten roles named and described, four sequenced into the first horizon, a devolution rule for compliance, and a sourcing approach that runs three routes in parallel: upskill existing staff, hire permanently, and bring in contract skills to cover the lead time on the other two. No hires are reported. There is no headcount per role, no cost per role, and the pack says in its own words that further scoping is needed to quantify the cost areas. This is a plan that was designed carefully, not a result that was measured.
Three things about it hold up, and one does not.
The reusable object is the rule, not the list. "Staff this locally where regulations differ" transfers to any group running one platform across markets that do not share a rulebook, and it survives whichever regime is current. Most organisation designs write the answer and lose the condition that produced it, which is why they stop being true the moment a market changes.
Early compliance only pays if the role holds a build lever. Sitting in the first horizon is necessary and not sufficient. The version that works has the role owning entries in the pipeline specification: what may be collected, how long it is kept, what a derived field is allowed to be used for, and a lineage trail that can answer, months later, which inputs produced a given decision. The version that fails has the same person in the same meeting with a sign-off box and no write access to the design.
Lifetime model quality belongs in the first wave, not the second. Deferring it was the one clear sequencing error, and it is the error the current generation of deployment practice exists to correct. The instrumentation that tells you a model has drifted is built into the first pipeline or it is retrofitted at several times the price, and the same is true of the record of what each model actually saw.
The cautious language-model pilots now appearing in this industry, reading job descriptions and summarising applications, do not change any of that. They raise the stakes on exactly the question this table answered early: who decided what the system was allowed to read, and can that decision be reconstructed. Our Consult engagements open there, because a pilot that cannot answer it is a demonstration rather than a capability.
Hiring the compliance role first does not make a platform compliant. It makes the constraint a design input while the design is still cheap to change, which is the only window in which a constraint is ever cheap.