Executive Summary
You're a founder, perhaps at Series B or C, and your data is becoming a problem. You're weighing up hiring a full-time Head of Data for £120k+ against bringing in someone fractional.
In my experience, neither route quite solves the problem. A new hire often spends their first six months just finding their feet and understanding the politics. A fractional consultant might give you a strategy document and then leave. Either way, you spend a lot of money and the underlying issue remains.
I think it helps to look at the problem differently. It isn't really about headcount, it's about the structure of your reporting. You need someone to fix the system itself, an architect, rather than a manager to sit on top of the existing complexity.
The common dilemma: a full-time hire or a fractional one?
This is a situation I see quite often in scaling businesses. The board is asking for numbers, and you don't feel confident standing behind them. Your Head of Sales has one version of churn, your Head of Product has another. The early-stage team who could patch things together with spreadsheets are now overwhelmed. It's a painful spot to be in, and hiring a Head of Data feels like the logical next step.
This leads to the dilemma. Do you commit to a senior, full-time hire at over £120,000, hoping they can sort it all out? Or do you find a fractional lead, which can sometimes feel a bit like a sticking plaster?
I've found this isn't always the most helpful way to frame it. The problem usually isn't a person-shaped hole in the org chart. You've probably already invested in good tools: perhaps Snowflake, dbt, and Looker. The trouble is, this can sometimes just mean you're migrating a messy process and making it faster. Automating a broken system just produces unreliable data more quickly.
Why a new hire often spends six months on discovery
In my experience, the main difficulty with the 'hire a Head of Data' plan is that you're often asking them to solve a political problem, not a technical one. The issue isn't usually a slow database. It's that Marketing and Product have different, unstated definitions of what an 'Active User' is.
A new hire, however good they are, will likely spend their first six months getting to know people. They have to become a sort of data archaeologist, digging through old code and interviewing people to understand years of undocumented decisions. They often end up presenting back the very problem you hired them to fix. You end up paying a senior salary for discovery work, not for fixing the underlying system.
I worked with a high-growth marketplace where this exact thing happened. They would spend a good part of every Monday morning arguing about whose numbers were correct. The new data lead suggested buying a new tool, but this was really misdiagnosing the problem. The tools weren't the issue, the lack of a shared understanding was. The core of a successful Data Strategy is agreement, not software.
A different approach: focus on architecture first
There is another way to approach this, which I think gets to the root of the problem. Instead of hiring a manager or a strategist first, bring in an architect.
My work isn't about managing a team or writing a long strategy document. It's about being a hands-on Reporting Architect who actually fixes the system. This usually happens in three phases:
What we're really doing is a bit of political engineering, using data architecture as the tool. It helps achieve the alignment on metrics that a new hire might spend their first six months asking for.
A note on what this requires from you
I should be clear, this approach isn't a passive one. It works best when the Founder or CEO is actively involved. You can't really delegate the final call on what 'Net Revenue' means, for example. Putting a Single Source of Truth in place can be uncomfortable. It often means teams can no longer rely on their own spreadsheets to present their numbers in the best light. You should expect a bit of resistance.
My experience is that you might need to slow down for a few weeks to get this right, in order to move much faster for the next few years. It's an investment in the foundations, not a quick fix. We are fixing the foundations so the ambitious AI project doesn't fall over.
The aim is to create a stable, documented, and properly governed data setup. Once that's in place, you're in a great position to hire a more junior, execution-focused data lead for a fraction of the cost. You'll be handing them the keys to a well-run machine, not asking them to fight a fire.