Perspective from the field: an interview with Marco Hoppenbrouwer, CDO at Stedin
For years, the Chief Data Officer role centered on data quality, governance, and infrastructure. Now that AI is moving from experimentation into production, the role also has to cover process, policy, and business transformation. For many organizations, that raises an uncomfortable question: where does this role actually belong? And who is responsible once a system no longer just advises but acts autonomously within a business process?
Marco Hoppenbrouwer, current CDO at grid operator Stedin, built a data organization at Shell and then transformed Stedin’s Data Office into an integrated organization for data, processes, and AI, tripling the organization’s size in the process. That experience gave him a unique perspective on how the role of data organizations has changed in recent years. We asked him what that shift looks like and what organizations can do today to prepare for it.
“The CDO role is an evolution. It starts as a data back office or a shared service for data. The next step is adding analytics and AI, because the two are inseparable. But the process layer is the crucial third step, because without that layer you don't know what you're actually trying to optimize.”
The CDO role is evolving
Hoppenbrouwer describes the CDO role not as a fixed function, but as a role that develops in stages. That conviction grew out of a concrete roadblock at Shell. There, he started as the company’s first global webmaster and architect, later CIO for mergers, acquisitions, and investments, and eventually led the innovation department.
“I had implemented major digital business cases on one asset,” says Marco. “When I wanted to repeat them on another asset with the same physical equipment, it didn’t work. The data standards and definitions were different everywhere.”
That gap proved to him that a separate data function was needed. And that the role had to go beyond the simple management of data. “The CDO role is an evolution. It starts as a data back office or a shared service for data. The next step is adding analytics and AI, because the two are inseparable. But the process layer is the crucial third step, because without that layer you don’t know what you’re actually trying to optimize.” Not every organization will take these steps in exactly this order, but Hoppenbrouwer’s point is the end state: without the process layer, the function lacks direction.
Hoppenbrouwer links process maturity directly to data quality. Organizations with strong process governance usually also have strong data governance, and vice versa. Most data quality problems originate in the process itself, either because validation within the system falls short or because the same work gets done ten different ways with no repeatable result. That’s why he brings data, process, AI, and application governance together under one structure instead of treating them as four separate mandates.
When he joined Stedin as Manager Data Office in March last year, there was a 107-page data strategy in place and a team of 30 people. That has since become an integrated organization of nearly 90 people. Responsibility for executing Stedin’s AI strategy was recently added to his remit, formally bringing data, process, and AI together under one mandate for him as well.
Where AI is already at work at Stedin
Hoppenbrouwer anchors the strategy in applications that are actually running, rather than sitting on a pilot roadmap. “We use models to predict where grid congestion will occur, and sometimes to decide whether to curtail a wind farm because the grid simply can’t handle the power. We also use models to determine how to approach grid reinforcement, combining cable capacity data with the local situation, such as ditches or rivers. Spatial constraints count too, such as making sure you’re not placing a transformer station next to a schoolyard. There’s always a human in the loop to check the final recommendation.”
That human check on the final recommendation is currently straightforward to organize, because the systems only advise. As systems start taking autonomous steps within a process, control shifts to that process, and with it the question of who owns it. That makes the process layer no longer an organizational choice, but a precondition for being able to govern AI in production.
Besides that, Stedin is using AI in two other areas, addressing capacity problems rather than costs. The first one is in customer contact centers, which are currently overwhelmed by calls about grid restrictions and new prioritization rules under energy legislation. There, they are testing a generative AI assistant. While the second application is internal, where design standards and manuals are being converted into a Q&A tool for contractors working in the field.
From data strategy to execution
His first move at Stedin was to test the priorities the organization had set. When he was told everything was equally important, he didn’t believe it, and went looking for the one initiative on which the board’s own success depended. That turned out to be resolving grid congestion bottlenecks, which is currently threatening the pace of the Dutch energy transition. He sat down with the responsible program manager and offered to build the solution together rather than prescribe it.
Together they developed an approach he calls “from data to delivery,” built around a competency new to Stedin: data product management, tied directly to a concrete business outcome. “Data isn’t always sexy,” he says. “But you want to be relevant. The moment you take on risk and accountability for the business outcome, you usually find a sponsor quickly.”
A business leader with a data and AI portfolio
Asked what sets the role apart, Marco draws a sharp line between a CDO and a technology leader who happens to also manage data. “A CDO is a business leader with a data and AI portfolio, not a technical portfolio. Many CDOs come from IT, but you have to think commercially and in business terms. You’re constantly translating: how do data, AI, and processes make the organization better, and what do I need to ask of my people to make that possible?”
At Shell, where he spent six years helping build the CDO department, he approached this not by starting with a data audit, but by visiting every business vice president to ask about their priority, then working backward to the data dependency behind it. One example became an internal reference point. When a facilities department claimed data was irrelevant to a major outsourcing deal, he pointed out that the contract would eventually expire and asked what data Shell would get back at that point. The final contract terms locked in ownership of, and access to, the data generated during the contract, a clause the supplier had never seen from a client before.
Get our report on the CDO role in the era of AI
Download the report to see how data and AI leaders across the Netherlands are redefining the CDO role.
Think big, start small: capacity close to the business
Hoppenbrouwer wants most of the capacity to eventually sit close to the business, in decentralized hubs rather than a central team. His caution concerns the sequencing, not the intent. “Think big, start small. You want to decentralize as much as possible, but the condition is that the organization can actually execute it responsibly. Without strategic direction over decentralized work, you have no guardrails at all.”
In the model he’s building, strategy, standards, and deep expertise stay centralized, while execution teams get embedded within business functions, such as asset management. The transition runs in three phases: demonstrate, do it together, and then let the business unit run it independently. A data scientist hired for a business unit, for example, is first trained within the central data organization and only placed once fully competent. That frees up central capacity again, so the center keeps building and transferring knowledge.
The price of scaling up
Growing from 30 to 90 people forced specialization within a team that used to do a bit of everything. Hoppenbrouwer is candid about what that transition cost. “People find specialization hard. They used to do a bit of everything. Now they own a small piece and lose sight of what the rest of the team is doing. In those cases, cohesion can be hard to maintain.”
During the scale-up, he says the team also lost some of its original strength in mutual connection, something that’s now being rebuilt. “Looking back, we should have spent a bit more time on our own transition instead of only managing the organization’s transition. That’s my biggest lesson learned. We’re addressing it now, with dedicated capacity, but as a leader, you need to manage your own transition too.”
