Head of Data: Builder vs. Strategist? The Wrong Question

Executive Summary

---

Why your technical skills are no longer the answer

You were very good on the tools. You could write the SQL query that made sense of a messy situation, build the dashboard that people actually used, and fix a dbt model quicker than anyone. That's why they made you 'Head of Data'.

And now you're starting to feel a bit out of your depth.

Your calendar is full of meetings. You spend your days refereeing disagreements between Marketing and Finance about the correct definition of an 'active user'. Your team, which used to be responsive, is now a bottleneck, and every new request feels like a problem you can't solve. You haven't committed any code in weeks, and the skills that earned you the job now feel redundant.

In my experience, this happens in almost every growing business. The move from 'Lead' to 'Head' isn't just a step up, it's a move to a different ladder entirely. The company has grown past the point where one skilled person can fix everything. The problem seems to have shifted from the code to communication, process, and the relationships between teams.

Solving political problems, not technical ones

What's often happening is that you're trying to solve architectural problems with the same tools you used as a builder. You may have invested in a modern data stack, but all that's done is help you migrate the mess more quickly. Automating a broken process just means you generate bad data at an impressive speed.

The company's main challenge is no longer technical. It's political. The reason the sales director's revenue number never matches the finance director's is not a SQL join error. It's because they have never been required to agree on one, single definition. Your job is no longer to write the query. It's to get the two of them in a room, perhaps with tea and biscuits, and not let them out until they agree. That's the real work now.

I once worked with a scale-up where the Monday leadership meeting began with a 30-minute argument over whose sales numbers were right. The data team would then spend the rest of the day trying to reconcile them. We fixed it not by building another dashboard, but by facilitating a very direct conversation that produced a single, governed Metric Definition in their semantic layer. The arguments stopped immediately. The work was political, just disguised as data architecture.

Your new job: designing the system

The way forward is to stop being the most skilled player and become the person who designs the stadium. Your value is no longer in your speed on the keyboard, but in your ability to design a system where your team can do good work and the business can trust the results. This isn't 'management' in the usual sense; it's a significant change in your Data Team Strategy.

Your new responsibilities look more like this:

Building trust in the data: You do this by creating a Single Source of Truth. This is a political achievement that requires you to mediate between departments and ensure consistency. It's about building faith in the data, which has to happen before you can build a successful data culture.

Protecting decisions from bad data: You need to put in place some light Data Governance. This isn't about writing long documents that no one reads. It's about automated checks, clear ownership, and a well-documented semantic layer that stops the CEO using the wrong number in a board meeting.

Making the team more effective, not just bigger: Your aim should be to make your team more capable, not just to hire more people. This means rethinking your Data Team Structure to shift from a simple service-desk model towards enabling experts in other parts of the business.

The difficulty of stepping back

This change isn't easy. For a while, it might feel like you aren't doing any real work. Your sense of productivity has to shift from 'pull requests merged' to 'arguments resolved'. You have to trust your team to do the technical work, even when you know you could probably do it faster yourself. That is the job now.

Department heads might not like it. They are often quite attached to their own spreadsheets and metrics. Persuading them to give those up is a negotiation, not a technical task. You have to be willing to move more slowly for a few weeks to build the foundations that will let the whole company move faster for years to come. This is the central problem when people ask if they need a builder or a strategist, but as I've said before, asking about a Head of Data: Full-Time vs. Fractional? is the Wrong Question. The real question is about the architecture.

That feeling of being out of your depth is a signal. It's telling you that the role has changed, and you need to change with it. It's an uncomfortable feeling, but it's a sign of progress. The relief when you have a team that can scale and leaders who trust the numbers is worth the temporary discomfort.