Here’s the uncomfortable bit: the CTO and Chief Data Officer roles are not the top of the engineering and data career ladders. They’re something else entirely. And if you treat them as promotions, you’re going to have a bad time.
I know, I know. You’ve been a senior engineer for years. You’ve led teams, shipped products, wrestled with legacy systems at 3am. Surely the next step is CTO? And for the data folks — you’ve built pipelines, wrangled stakeholders, delivered dashboards that actually get used (rare, I know). CDO must be the finish line, right?
Wrong. And I say this as someone who has sat in these seats. The jump from “most senior technical person” to CTO or CDO isn’t a step up. It’s a step sideways into a completely different job. One that happens to require technical knowledge, but isn’t really about technology at all.
The job changes underneath you
Let’s be blunt about what happens when you move into a C-suite data or technology role. You stop being the person who solves problems, and you become the person who decides which problems are worth solving. That’s a fundamentally different skill.
A great staff engineer looks at a system and asks “how do I make this work better?” A CTO looks at the same system and asks “should we even be building this, or should we buy it, or should we ignore it entirely and focus somewhere else?” The CDO equivalent is the person who stops asking “how do we model this data?” and starts asking “what decisions does this business need to make, and where do we find the missing information?”
These are strategy questions. They’re about scope, about where a company puts its finite time and money. And here’s the thing that catches a lot of people off guard — you don’t need to be the best engineer or the best data person to answer them well. In fact, being too attached to the technical craft can actively get in the way. I’ve seen brilliant engineers become terrible CTOs because they couldn’t stop optimising systems and start optimising outcomes.
The skills that make you excellent at the craft — deep focus, technical rigour, a drive to build the best possible solution — can become liabilities at the strategic level. Because at the C-level, the best possible solution is often “good enough, shipped fast, pointed in the right direction.” That’s not a comfortable thing to hear if you’ve spent fifteen years caring deeply about code quality.
Data is your moat. Treat it like one.
Most companies, whether they know it or not, are sitting on what could be their most defensible competitive advantage. Their data.
Think about it. Your product can be copied. Your features can be replicated. Your pricing can be undercut. But the specific dataset you’ve built up over years of operating — the patterns in your customer behaviour, the operational signals that tell you where you’re leaking money, the relationships between variables that only become visible at scale — that’s yours. Nobody else has it. And if you’re using it well, nobody can compete with what it tells you.
This is the product moat that most companies desperately need and almost entirely ignore. Not because they don’t have the data. They do. But because the person who understands what to do with it — the CDO — is almost never in the room when strategy gets discussed.
And this is where it gets frustrating. The CDO, in most organisations, gets brought in as an implementer. “We’ve decided we need to be data-driven” (shudder), “so we’ve hired someone to build the infrastructure.” The strategy has already been set. The priorities have already been decided. The CDO’s job is to execute. Which is a bit like hiring a navigator after you’ve already set sail and telling them their job is to polish the compass.
The CDO should be part of the conversation about where the ship is going. Because they’re often the only person in the room who can see what the data is actually saying about the business. Not what the dashboards say — dashboards are rearview mirrors. I mean the deeper patterns. The things that suggest your best customers are about to churn, or that the market you’re investing heavily in is already saturated, or that there’s an adjacent opportunity nobody has noticed because it doesn’t show up in the quarterly revenue figures.
When the CDO is treated as a strategy partner rather than a technical hire, the quality of decisions improves. Not because they have magic insight, but because they bring a different lens. They’re trained to look for signal in noise, to question assumptions with evidence, and to be honest about what the numbers actually say rather than what everyone hopes they say.
But this almost never happens by default. It has to be intentional. The CEO has to want it, and the CDO has to be capable of operating at that level — which, circling back to my earlier point, is a very different capability from being good at data engineering or analytics.
You can’t solve a strategy problem with an org chart
Here’s something I see regularly. A company reaches a certain size and decides it needs a CTO or CDO. So they promote their best engineer or their most senior data person. It makes sense on paper. This person knows the systems, knows the team, knows the history. But within six months, everyone’s frustrated. The new CTO is drowning in board meetings and vendor negotiations. The new CDO can’t get traction because they’re still thinking about pipeline architecture when the real problem is that the sales team doesn’t trust the numbers.
The issue isn’t that these are bad people. They’re often excellent. The issue is that the role they’ve been given doesn’t match the role they prepared for. Being a CTO isn’t a reward for years of good engineering. It’s a different job that requires comfort with ambiguity, commercial awareness, the ability to influence without formal power, and a willingness to make decisions with incomplete information. Same goes for the CDO.
And I’ll say something that might be unpopular: many companies would be better served by hiring a CTO or CDO who is less technically deep but more commercially sharp, than one who is a technical wizard but can’t hold their own in a strategy conversation. The technical depth can be delegated. The strategic thinking cannot.
You need this earlier than you think
There’s a common assumption that CTO and CDO roles are for big companies. That startups and scale-ups should just hire engineers and get on with building. I think this is wrong, and it’s costing companies time and money.
Even early on — especially early on — you need someone who can think about technology and data at the strategic level. Not because you need a big team or an expensive infrastructure. But because the decisions you make early about what to build, what data to collect, and how to structure your technical approach will either make your life much easier or much harder in two years’ time.
I’ve seen startups build their entire product on a database choice that made sense for the first six months and became a nightmare at scale. I’ve seen companies collect reams of data with no thought about how it would be used, then spend a fortune trying to retrofit structure onto chaos. These aren’t engineering failures. They’re strategy failures. And they happen because nobody was asking the right questions early enough.
You don’t need a full-time CTO or CDO from day one. But you do need access to someone who thinks like one. Someone who is product-aware, commercially minded, and able to connect technical decisions to business outcomes. Someone who can look at your roadmap and tell you where the risks are, where the opportunities are, and where you’re about to spend money on something that won’t matter.
That’s what I do
I work with companies — early stage through to established businesses going through a transformation — to provide the strategic direction that a good CTO or CDO brings, without the overhead of a full-time C-suite hire before you’re ready for one. I help founders and leadership teams make better decisions about technology and data, connect those decisions to real business outcomes, and avoid the expensive mistakes that come from treating these roles as purely technical.
If any of this sounds like something you need, I’d be glad to have a conversation about it.
This post also appears on my Substack.