Three underappreciated success factors of Chief Data Officers

Willem Koenders
ZS Associates
Published in
11 min readMar 9, 2023

--

A survey found that >80% of Fortune 1000 organizations now report to have a CDO in place. With this percentage steadily increasing, ever more detailed evidence is emerging explaining why some CDOs are successful where others fail.

After providing a quick recap of the most commonly referenced success factors, I’ll offer three of my own recommendations that are especially important at the personal level of the CDO:

  1. Build a strong personal relationship with a couple of peers
  2. Have a simple framework and implementation approach
  3. Go the extra mile in one particular technology

Common recommendations and success factors

Here are a couple of uncontroversial, oft-cited recommendations and success factors for CDOs as they get started:

  • Understand the business and align with business strategy. A CDO that has a strong understanding of the organization’s industry, market position and competitive landscape is better able to identify opportunities for data-driven insights and to develop strategies for leveraging data to drive business outcomes.
  • Focus on data-driven value quantification. A corollary to the previous recommendation is to identify use cases as the connection between data capabilities and business outcomes, and to have a methodology in place that can be used to calculate and monitor value creation.
  • Start small, scale after. Perhaps the least controversial recommendation, and almost a truism, is to take a certain scope — e.g., a domain, business process or functional area — to experiment with data capabilities and management, to fail fast and learn, and to afterwards scale across the rest of the organization.
  • Use domains as the cornerstone under data stewardship. When data is owned and managed by domain experts who understand the context and purpose of the data, they are better able to ensure its accuracy, completeness, and consistency.
  • Be the bridge between business and technology. One of the reasons that CDOs are on the rise is that it was never clarified who, between the business and IT, is truly responsible for the data. As a CDO, there is an opportunity to have a so-called purple profile, a combination of technical (red) and business (blue) skills, to ensure that the business and IT are aligned in terms of data management in general, and capabilities like a data platform in particular.
  • Ensure that a sound, realistic data strategy is in place. Data is complex — in terms of the multitude of data capabilities it involves, the internal stakeholders in your organization, and the literally 100s of potentially relevant data technologies out there that could help. You cannot fix it all, which is why a data strategy is so important to provide clarity about the mission and specific objectives.
  • Gather a strong team around you. Perhaps it seems obvious — any leader would benefit from a strong, talented team — but it becomes extra important considering that a CDO often has to oversee capabilities such as metadata management, data architecture, data cataloguing, data privacy, data science and data integration. It’s hard enough to be an expert in any one of these areas, but covering them all is just not practical, and potentially a risk. Having trusted leads for the most important disciplines will greatly alleviate the day-to-day burden on the CDO, who can direct attention to other, more value-adding activities.
  • Build a data culture. Data is created, owned, and touched by people across the organization, who should feel encouraged to make decisions based on trusted data that is available to them. Driving data literacy across the organization is a continuous effort that ensures that data is used with care and integrity.

Three additional, personal recommendations

Based on real-life experiences with over 25 Chief Data Officers, I would suggest three additional considerations. They are relevant at the personal level of the CDO’s personal career development.

1) Build a personal relationship with a couple of peers

Personal relationships matter. You can have all the foundational capabilities in place — identified use cases, the right technology, highly touted talent— but if there is no basic trust, the result will be failure.

I worked with two Chief Data Officers that faced a very similar struggle, despite being in different companies and sectors. Both were highly competent data leaders, with credentials and expertise across key areas such as data governance, data quality and data platform enablement. They created an upbeat, ambitious and expansive data strategy, with a lot of details on the organization’s existing data maturity and ideas for enhancement, all revolving around a theme of driving business outcomes. But both struggled immensely to get traction on the business side of the organization. Based on experience with previous data leaders in their companies, where data programs had demanded a lot of time and budget yet failed to achieve business success, these business leaders saw data management as a blocker — something that would delay and complicate their already full agendas. When presented with frameworks and RACI-tables across topics like data quality and issue management, they rightfully understood that these implied responsibilities for them to step up as data owners. When discussing data science and its enablement, they felt protective and acted territorial — they themselves had ideas and ambitions in this area, the use cases that would benefit were part of their business areas, and they did not want to “give up” the AI and analytics talent in their own teams. After a full year, although some progress had surely been made, virtually no business impact could be discerned.

By contrast, another data leader prioritized time in the first three weeks of her tenure to talk one on one with some of the business leads in her organization, that are considered as peers. She arrived to the chats without a detailed agenda or complicated framework. They talked about the business, past experiences, what data-related pain points had been, and what the goals could be for the near future. With some business leads, traction was moderate, but with one particular business lead, she hit it off right away. They enthusiastically exchanged perspectives and naturally gravitated towards a particular area (in this case, mastering data for a specific sub-domain) that had been causing a lot of issues and inefficiencies, and where they could truly help each other out. They mobilized relevant people in their respective teams, agreed on a limited scope, put a simple roadmap together, and went to work. This data-business collaboration led to initial success and from it, best practices, a framework, and standards were generalized for the rest of the enterprise. A personal relationship blossomed, with both leaders crediting the other’s team for their critical inputs. The impact was socialized across key stakeholders, and formed the initial jumping-off point for new data-driven modernization efforts.

Not every story will be like this, but it can be derived that despite all the fancy technology-speak that’s out there today, in the end it’s all about people, and personal relationships matter. This is true in general, but even more so for data leaders, whose success critically depends on the interaction and collaboration with business and technology teams. You can follow all the general recommendations of the initial section of this point of view, but if you cannot build a relationship of mutual trust with key counterparts in business and IT, you will fail. Therefore, identify one or two relevant leaders, and invest time and effort to build trust upfront.

2) Have a simple framework and implementation approach

Data management is complex. There are many data capability areas, including those related to data governance, data architecture, data quality, integration and interoperability, data storage and operations, data science, metadata, master data, and data warehousing. These capability areas are tightly interconnected and depend heavily on each other. For example, data quality cannot be measured without appropriate metadata and governance standards, and data warehouses should align with data architecture, storage, and interoperability guidelines. Hardly anyone is an expert across all of these areas, let alone in explaining how they should all work together.

For that reason, it’s a huge accelerator if you can explain in simple terms how your organization should go about managing its data. A simple framework can work wonders to translate complex data concepts and terminology into an approach that anyone in the organization can understand and get behind.

Consider the following implementation approach, based on an example in the insurance sector:

The respective data leader had a particular mandate to bring data under governance across so-called, critical data domains. The above diagram enabled this leader to explain the implementation approach whenever necessary. There were four specific teams, each with specific responsibilities and capabilities. The Data Governance team prioritized the data domains and related scopes for which data was to be brought under governance. Next, a team focused on Metadata Management would identify systems, flows and related minimally required metadata for the prioritized scope. This metadata was the input Data Quality Analysts needed to be able to measure and track data quality. Based on produced data quality metrics, issues could be observed, which in turn formed the input for Data and Issue Owners to log and take ownership of the respective issues, investigate root causes, and create remediation plans. Across this flow, the Data Governance team would organize a Data Governance Forum to track progress and resolve any implementation issues. Of course, each scope and capability faced a set of challenges, but the approach was always crystal-clear and well-understood, driving buy-in from necessary business, technology and risk teams.

Although the end product here may be a specifically slimmed down and simplified diagram, it may take some time to get it right. Indeed, as Steve Jobs said, “You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.”

3) Go the extra mile in one particular technology

There are hundreds of relevant data technologies. Any of them could be relevant for a Chief Data Officer, with many of them overlapping in terms of the capabilities they offer. It is impossible to know them all, and being a true expert at just a handful of them will be challenging.

An overview of relevant machine learning, AI, and data technologies for 2023.
Matt Turck’s Machine Learning, Artificial Intelligence, and Data Landscape.

At the same time, having the right technology in place can immensely simplify and streamline data management processes. Any data process that is manual is typically expensive and prone to human errors, and therefore to be avoided. In other words, quite literally any data management process should be technology-powered.

Data leaders typically have a good understanding of technology-agnostic data capabilities and requirements. But for specific technology expertise, they rely on their IT counterparts. To a large extent, that is appropriate — the last thing I’d advocate for would be for the CDO to absorb all technology responsibilities. But there is a practical consideration that CDOs that have a minimum understanding of a relevant set of data technologies are much better able to assess what feasible implementation approaches could be and what data management processes can be automated, and to drive executive buy-in for these technologies.

On a personal level, it gives a CDO a higher credibility with IT counterparts (even more so through achieved certifications), as they can be spoken to in their own language, and as specific technology implementation and configuration nuances are understood immediately. In front of business stakeholders, CDOs also enjoy an increased credibility in terms of conveying the benefits, risks and business case of specific tools.

Which technology to deepen expertise in depends on the organization and its unique context in terms of business objectives, existing pain points and current data landscape. That said, a few categories can usually be identified, from which a particular focus could be distilled:

  • Data governance technologies. Tooling exists to enhance and automate data governance processes. These include data quality tools, data catalogues, metadata scanners and data protection and security applications. Several vendors, such as Informatica, provide a fairly complete suite of tools across data governance processes. Studying up on such a technology that addresses the organization’s data governance priorities and that fits within budget constraints (leading tooling typically comes at a $250k+ minimum annual cost) will directly enhance a data leader’s ability to advocate for and guide the implementation of such data governance tooling.
  • Data platforms. A suite of technology vendors have blended data capabilities to enable organizations to ingest data from different sources, process and curate it, and make it available for analysis and data science. Instead of managing the underlying infrastructure, such “data platform as a service” offerings enable organizations to focus on the data and its usage. CDOs for whom it is particularly important to enable data-driven use cases can therefore dive deeper on a vendor such as Databricks or Snowflake.
  • Data science technologies. Vendors such as Dataiku, DataRobot and Amazon SageMaker are examples of technologies that enable organizations to build, test, deploy and maintain AI and ML models. Becoming familiar with such a vendor can be especially helpful for CDOs who are expected to provide the data and capabilities to enable data scientists, or who are leading data science teams themselves.
  • Cloud technologies. It can make sense to pick one of the dominant technologies (e.g., AWS, Azure, Google, Alibaba) if you are in an organization that has committed to a particular cloud vendor, or that is pushing a cloud migration agenda. In one example, a regional bank’s leadership communicated a cloud-first mindset and committed to MS Azure as their strategic cloud vendor. Having a good understanding of Microsoft’s Cloud Adoption Framework enabled the incoming Chief Data Officer to very precisely define how Landing Zones could be used to build and scale data capabilities, how the MS Common Data Model could be used to kickstart the implementation of its enterprise data model, and how MS Purview could be configured to drive data governance and lineage by design.

Whichever technology is most important for you, the good news is that generally no matter which vendor you pick, you conceptually understand alternative technologies reasonably well as well, as they have very similar building blocks.

Summarizing, although it might seem slightly “out of the wheelhouse” of a CDO, those who deepen expertise in a relevant technology are better equipped to drive tactical implementation efforts. And with online learning platforms like Coursera and Udemy, you can become “an expert” much faster than you might think.

Closure

The following overview summarizes the resulting success factors for Chief Data Officer (and other data leaders). Good luck and let me know if I missed a particular recommendation!

References and recommendations for further reading:

--

--

Willem Koenders
ZS Associates

Global leader in data strategy with ~12 years of experience advising leading organizations on how to leverage data to build and sustain a competitive advantage