"We want tech to have more impact." Really?
A call I got a few weeks ago, and everything it says about how we still get tech and product organization wrong.
This week I want to tell you about a phone call. Nothing spectacular, but one of those five-minute conversations that sums up a problem I see everywhere.
A recruiter reaches out about a CTO/CIO role, reporting directly to the CEO. On paper, exactly the kind of mandate I like: the company wants tech to carry more weight, to stop being a cost center you put up with and become a real driver of the strategy. They talk about impact, product, transformation. I listen, interested.
And then, as the conversation goes on, the picture sharpens. Alongside this CTO reporting to the CEO, they’re creating a Head of Product role. Reporting to the COO. Not to the CTO, not to the CEO — to the COO. And to staff this new product org, they’re pulling the Product Owners out of tech and moving them under that Head of Product. POs who, in practice, mostly do delivery.
The rationale? “We want business-oriented product teams.”
I hung up thinking it was a textbook case. Not a bad one. A revealing one. Because it’s exactly the kind of situation where a next-generation CIO would add enormous value — and where, at the same time, the org being drawn up will stop them from adding any.
I’m telling you this anonymized, no company name. The point isn’t to single anyone out: the pattern I’m describing comes up far too often.
A next-gen CIO isn’t a CIO with a fresh coat of paint
First, let’s define the thing, because “next-generation CIO” is turning into a buzzword, and a buzzword soon means nothing at all.
We all know the “classic” CIO: solid on infrastructure, governance, information systems, risk and cost control. That’s valuable, and it isn’t going away. But that profile is often too far from the customer and from the speed of digital. Tech gets treated as a black box: you hand it orders, it ships, and nobody quite knows what happens inside.
The next-gen CIO holds both worlds at once. They keep the engineering bar high — quality, security, the technical debt you don’t let rot. And they add what’s most often missing: customer obsession as the north star. Not the customer as a slogan, but as the compass that settles the trade-offs day to day. A classic CIO already knows how to talk to the board and to the developers — that’s not where the difference lies. The difference is that they steer from the user’s problem and the impact created, not from project scope or the budget to hit. Honestly, it’s not a profile you find on every corner, because that kind of obsession can’t be decreed: either it shapes every decision, or it’s just a line in a job description.
What it changes in practice: they don’t think in “projects to deliver” but in “problems to solve” and value created for the user. That’s exactly what I tried to do at Bpifrance, where we shifted a large organization toward a product-led logic centered on user impact — and where having product, tech and data under one shared vision was the precondition for moving fast, not an org-chart detail.
The trap: mistaking intent for structure
Back to my call. The stated intent is good. “More impact for tech,” “business-oriented product teams” — who could be against that?
Except intent does nothing. Structure decides. And the structure I’m being described says the opposite of the intent.
Look at it coldly. You create a CTO reporting to the CEO to give tech more weight. Fine. And in the same move, you detach product from tech, put it under the COO, and pull the POs over to the product side. The result: the CTO is left with a “tech” responsibility amputated of half of what creates impact — defining what gets built and for whom. They become a slightly more prestigious delivery function, not really a strategic engine.
You’ve handed out a nice title and a nice reporting line, and you’ve hollowed out the role through the org chart sitting right next to it. That’s what I call the tectonics of organizations: it isn’t intentions that move the plates, it’s reporting lines, scopes, and who gets to decide what.
“Business-oriented” doesn’t mean “far from tech”
That’s where the core misunderstanding sits. People assume a false equation: for product to be business-oriented, you have to pull it away from tech and closer to operations.
It’s the exact opposite. A business-oriented product is one that genuinely solves a customer problem — fast, well, and profitably. And that plays out at the intersection of product, tech and business — not by building walls between them. When product and tech aren’t aligned, you don’t get more business. You get political trade-offs, priorities crushing each other, and teams spending their time passing the responsibility back and forth.
Putting product under the COO also sends a very clear signal, even if nobody says it out loud: product is operational, it’s coordination, it’s “keeping things running.” Not strategy. But a real Head of Product is someone who decides what to build to create value — it’s a vision function, not a back-office one. By having them report to the COO, you’re politely telling them to stay in their lane.
The real symptom: POs who do delivery
And then there’s that detail that isn’t one. Product Owners who do delivery.
If POs mostly do delivery, they aren’t Product Owners in the strong sense. They’re project managers with a new label. They don’t own the “why,” they manage the “how” and the “when.” And moving those POs from tech to the Head of Product doesn’t create a product organization. It moves a delivery team from one box to another and slaps a “product” sticker on it.
The problem isn’t fixed, just relocated. Worse: you now have delivery on one side of the org chart and tech on the other, separated by a reporting boundary. Anyone who’s read a bit of Team Topologies, or simply lived through Conway’s law, knows what comes next: the product architecture and the fluidity of the teams will end up mirroring that boundary. You’re manufacturing silos — and eighteen months from now you’ll wonder why “it’s not fast enough” and why “product and tech don’t talk to each other.”
What a next-gen CIO would have said in the room
That’s why I say this is exactly the kind of situation where that profile adds real value. Not because they’d have a fancier title. Because they’d have asked the right questions before drawing the org chart.
They’d have started with the problem, not the boxes. What impact do we want, for which customers, measured how? Only then: what organization serves that impact? And at that point they’d probably have said you don’t give tech more weight by cutting it off from product — you do it by bringing product, tech and data under one shared vision, with a real reporting line to the CEO, and by turning POs from delivery conveyor belts into owners of the problem to solve.
I’m not saying there’s only one right setup. It needs to be challenged; it depends on the company’s maturity, its sector, its people. But the reflex of splitting by function and spreading the pieces under different managers “so everyone has their scope” is often the shortest path to no one owning the impact end to end.
And the trap is that all of this starts from good intentions. People want to do the right thing. They want to “give tech more impact.” But they reason in org charts before they reason in value, and the org chart ends up deciding for them.
The question I’ll leave you with
I didn’t take it further, to be transparent. Not out of pride — but stepping into a process whose structure already contradicts its ambition was a bad start.
It did leave me with a question, though: how many companies today are convinced they’re “giving tech more impact” by creating a shiny CTO role… while building, right next to it, the very organization that will stop them?
If you’ve lived through this, on either side of the table, hit reply — I read everything, and those replies tend to spark the best conversations of the week.
Talk soon, Nicolas
PS: if this resonates, feel free to forward it to a leader or peer in the middle of rethinking their tech/product org. These questions are usually worth asking right when the org chart is being redrawn.