Executive Summary
You need to hire your first Head of Data, but you're not sure whether you need a hands-on builder or a high-level strategist.
Hiring the wrong type of person first is a common and expensive misstep. The builder can create technical work that isn't quite what the business needs. The strategist can deliver a good plan, but with no one to build it, leaving you back where you started, but with less money in the bank.
It might be the wrong question. For a scale-up, your first senior data hire is often neither. You need a Reporting Architect: someone who can design how reporting should work before you hire a larger team.
A common dilemma: the 'Builder' vs. the 'Strategist'
I see this situation quite often in Series A or B companies. You've just raised a round, the board is asking for better metrics, and your spreadsheets are starting to creak at the seams. There's real pressure to hire a 'Head of Data', and the debate usually splits into two camps.
Camp A: The Builder. This argument is for a hands-on Analytics Engineer. Someone who can get into the details, write SQL, build dbt models, and produce the dashboards the business is keen to see. They can get the immediate chaos under control and give you something tangible to look at. The appeal is understandable: you get something useful, quickly.
Camp B: The Strategist. This view, often preferred by the board, is to hire a VP of Data from a larger company. They won't be writing code, but they will create the three-year Data Strategy, design the organisation chart, and present a compelling vision to investors. The appeal here is a credible, long-term plan.
So you're a bit stuck. One feels like a short-term fix, the other a long-term luxury. It seems you need both, but it's not clear which one should come first.
The problem with hiring either one first
In my experience, hiring either one in isolation can be a quick way to burn through that investment. You may have already moved to the cloud and hired some good engineers. The risk is that you've just found a way to make the same mess, only faster. Automating a tangled process just produces confusing data at speed.
What happens when the Builder starts first:
You hire a brilliant technical lead. They immediately start building. But without a coherent, top-down business strategy, they are working without a clear map. They build what's technically possible, which isn't always what the business actually needs. The result can be a set of dashboards that are technically sound, but don't quite help the business make decisions. Finance still doesn't trust the numbers, marketing complains the definitions are wrong, and the builder gets frustrated with a constant stream of ad-hoc requests. This often creates a Data Engineering Bottleneck that slows everyone else down.
What happens when the Strategist starts first:
You hire the impressive VP. They spend their first 90 days interviewing stakeholders and produce a very thorough slide deck outlining your future data organisation. The difficulty is that your data team might just be one busy analyst. The strategist has designed the engine for a sports car, but you've only got the parts for a family saloon. The plan sits on a shelf. The board gets impatient. The strategist, who is used to having a large team, can get frustrated and may well leave. You're left with an expensive document you can't act on.
A third option: the Reporting Architect
The answer, I think, is to sidestep this choice altogether. Your first senior data hire doesn't have to be a pure builder or a pure strategist. I've found a hybrid role works best: the Reporting Architect.
This is a bit of a 'player-coach' role. It's for someone who has done the hands-on work in the past and remembers how everything fits together, but whose main job now is to design the system. Their role isn't to build everything themselves, nor is it to create a strategy in isolation. It's to design the factory before you start hiring the factory workers.
Their first hundred days or so would look quite different from the other two:
Once this foundation is in place, they can help you write the job descriptions for the next people you need to hire. And by this point, you'll have a much clearer idea of who you need. You don't need a generic 'data analyst'; you need someone to manage the Looker instance and train business users. You don't need a generic 'data engineer'; you need someone to improve the marketing attribution pipeline.
The trade-off: this approach can feel slower at first
I should be honest: this approach will feel slower to begin with. Your new architect will likely spend their first month in meetings and at the whiteboard, not writing code. They will probably say 'no' more than you're used to. They will have to bring department heads together for some tricky conversations, especially when those teams have been running on their own spreadsheets for years. This is the difficult but necessary work of untangling disagreements so that useful data can finally flow properly.
It's a case of moving a bit slower for a few weeks, so you can move much faster for the next few years. It's a trade-off I've seen most successful scale-ups make eventually. This is how you build a solid foundation to solve your Scale-up Data Challenges properly.
By hiring an architect first, you're building a system that's designed to last. You can move from constantly fire-fighting to building something properly. You stop hiring people to manage chaos, and start hiring them to build on a clear foundation.