What a Fractional Head of Data & AI Actually Does

If you own the platform and the budget, the fractional Head of Data & AI is not a staffing convenience. It is a build-versus-buy decision about leadership itself — and like any such decision, it turns on whether the capability is a differentiator or a commodity. Deciding which metrics the board sees is a differentiator. Knowing the order in which a Fabric or Databricks estate should be untangled is not; it is a pattern someone has applied before, and you are buying the pattern.

This article is about what the role does on an ordinary week, what it should refuse, and the conditions under which it is the wrong purchase.

What problem is the role actually solving?

Almost never a skills gap. The engineers you have can usually build the thing. The problem is that nobody is authorised to decide which thing, in what order, at the expense of what else — so the backlog becomes a queue of equally urgent requests, each sponsored by someone senior, none of them sequenced against the others.

That produces a recognisable state: three half-finished ingestion patterns, a semantic layer that exists in two places and agrees in neither, a Power BI estate where the same measure is defined by whoever got there first, and an AI pilot that nobody can productionise because it reads from a dataset no one owns. None of that is a competence failure. It is an absence of a single accountable judgement about trade-offs.

The fractional lead’s product is decisions, with reasons attached, made quickly enough that delivery can resume. Not strategy documents. Decisions.

What does the first stretch of work look like?

The sequence matters more than the content, because the content is usually already known to the people doing the work. They have just never been asked in a setting where the answer binds anyone.

First: the commitment inventory. Every promise made to a stakeholder, written down, with who made it and what it depends on. This is uncomfortable and it is the whole job in miniature — you cannot sequence a portfolio you have not enumerated. Most of what surfaces here was never formally approved; it accreted.

Second: the ownership map. For each dataset, pipeline and report that something downstream depends on, a named human. Not a team. Where the name is blank, that is the risk register.

Third: the decision log. Open decisions, who can make each one, and what is blocked behind it. The log is the instrument that converts an advisory role into an accountable one, because it makes latency visible — a decision sitting unmade for weeks is now an artefact rather than a feeling.

Only then, the technical sequencing: what to stabilise, what to rebuild, what to leave ugly and working. That last category is the one a permanent hire in their first months often struggles to defend, and the one a fractional lead is structurally better placed to insist on, because they are not building a kingdom they will inherit.

What should the role refuse?

A fractional lead who starts writing dbt models has been miscast, and usually by mutual consent: hands-on work is legible, satisfying, and immediately useful, which is exactly why it displaces the harder work of saying no to a general manager. Some technical depth is non-negotiable — you cannot adjudicate a partitioning argument you do not understand — but the depth is for judgement, not throughput.

It should also refuse the maturity assessment as a deliverable. Scoring your organisation against a five-level ladder tells you what you already knew, in a format designed to be presented rather than acted on. The commitment inventory does the same work and produces an argument about next week.

And it should refuse single-threaded ownership of anything operational. If the fractional lead is on the escalation path for a failed load, the engagement has quietly become a staffing arrangement with a worse rate.

How does it differ from a contract architect?

The distinction gets blurred in procurement and it is worth keeping sharp.

	Fractional lead	Contract architect
Mandate	Sequencing and trade-offs across the portfolio	Design integrity within a chosen scope
Primary output	Decisions, with the reasoning recorded	Designs, patterns and standards
Spends time with	Sponsors, finance, the engineers doing the work	The engineers doing the work
Exit condition	A permanent owner can hold the decision log	The design is built and documented
Characteristic failure	Drifts into delivery and stops deciding	Produces a standard nobody adopts

You can need both. You cannot substitute one for the other, and buying an architect when the problem is unsequenced commitments produces an elegant target state that the organisation continues to ignore.

What team shape sits underneath?

The common error is hiring for the platform you intend to have. Hire for the platform you will operate for the next stretch, and keep the shape small enough that ownership is unambiguous.

The deferrals are the point. A dedicated AI engineering stream sitting on top of unowned datasets produces demos that cannot be promoted. A governance function created before there is anything to govern produces a catalogue of assets nobody queries. Both are easier to justify in a budget line than to live with.

One substantive exception: if a single capability is genuinely a differentiator for your organisation — the model that prices your product, the retrieval system over your own proprietary corpus — it belongs in-house early, and the fractional lead’s job is to protect it from the commodity work that will otherwise consume the same engineers.

When is this the wrong purchase?

The fourth case deserves emphasis. A fractional lead brought in after the trade-offs have been made elsewhere — in a vendor agreement, a transformation programme, a board commitment to a specific outcome — has authority over nothing that matters. The engagement will be judged on delivery it does not control. Decline it, or reopen the mandate before anyone signs.

How do you know it is working?

Not by throughput. Tickets closed, models built and dashboards shipped all rise when a team stops arguing about priority, which means they rise for reasons unconnected to whether the priorities were correct.

Better signals, all of them qualitative and all of them observable without instrumentation: how long an open decision sits in the log before it is closed; whether work gets abandoned mid-flight; whether the same metric dispute recurs after it was supposedly settled; whether engineers are being asked to re-derive context that should already be written down; and whether the people with budget are arguing about sequence rather than about whether the platform is any good. The last one is the clearest tell. Disagreement about order is a healthy organisation. Disagreement about legitimacy is not.

The honest exit test is simpler still. If the role ended, could someone already inside the organisation pick up the decision log and keep making the same calls for the same reasons? When the answer is yes, you have bought the thing you meant to buy.