What You Should (and Shouldn't) Expect From Your CDO

There’s currently debate among industrial leaders, digital evangelists, academic scholars and business researchers whether Chief Digital Officers (CDOs) are making a difference; if they’re needed going forward; and if so, what should their focus be. In fact, institutions such as Forbes and Forrester suggest we’ll see no CDOs five years from now. I thought I’d share my views on this and suggest four responsibilities that I believe must be led from the center to succeed with a technology- / data enabled transformation.

ALMOST EVERYONE HAS A CHIEF DIGITAL OFFICER

Before 2012, less than ~5% of companies had a Chief Digital Officer. In 2016, this number rose to ~20%. Today, two thirds of all companies have a CDO (i.e., one or more persons reporting at C-level with mandate over some combination of "data", "digital" and "analytics"). (Source: McKinsey, PwC, NewVantage Partners among others).

Internet innovators, notably Amazon, spent the first few years of this century making Internet into a billion (and later a trillion) dollar commercial channel. Companies realized they needed a C-level thought leader to establish and secure a competitive stance. The Head of E-Commerce was born.

Technology advanced towards ubiquitous connectivity, faster and cheaper data storage and processing, and paved the way for "digital" as a new way of doing business. New companies ("digital natives") with no traditional assets (e.g., media rights, land, housing, hotels, cars, air planes, trains etc.) were taking serious market share. Companies slowly realized there’s much more to these new technologies than e-commerce. They needed a C-level thought leader to establish and secure a competitive stance. The Chief Digital Officer was born.

So, what’s the CDO expected to do?

INNOVATOR, ORCHESTRATOR OR PLUMBER?

You find heaps of frameworks and best practices framing the CDO role. They all come to similar conclusions: It depends. They suggest different versions of approximately below trade-offs:

1. Why am I here? To innovate and show the art of the possible or enable and scale solutions?
2. How should I operate? Top-down through centralized initiatives or bottom-up by empowering business lines?
3. What does success look like? Functional enablement or end-to-end customer experience?
4. How’s my work prioritized and funded? Discretionary through central funding or via competition for funding on equal terms with the rest of the business?
5. Who do I report to? The CEO or a C-level business division?

Let’s dig into this. Think about CDOs you consider successful, by whatever standards you prefer. For instance:

• Consider the "digital evangelist". On stage telling their story. Arrived to find a conservative culture; Had to break all the rules and hire a bunch of rebels to show the art-of-the-possible; Developed awe-inspiring digital apps in record time.
• Or, consider the "platform builder". Rarely on stage. Their story is about building new platforms; Enabling the business to transform; Working hard to move away from old, legacy technology; Architects and engineers.

Here’s the catch: Can you come up with one CDO archetype that isn’t overlapping with an existing C-level responsibility? Please ping me.

Think about it. Take my two examples above:

• The digital evangelist CDO is technically running an internal startup, aiming to compete with the current company business model. Essentially, the CDO is the CEO of a competing startup without the associated independence nor upside.
• The platform builder CDO is likely doing what the CIO would like to do. Essentially, the CDO is asked to carve out the fun part of the CIOs job, and complete it with a fraction of the budget and people.

The result to date (shoot me for generalizing): Cool applications that won’t scale ("death by prototype"), and/or unfinished platform program with no useful business applications ("never ending plumbing").  

FOUR NO-REGRET CDO RESPONSIBILITIES

I believe there are clear and useful responsibilities for a CDO to take. To articulate them, let’s review four challenges likely facing every organization "going digital":

1. We are (or anticipate we’ll soon be) under business pressure from competitors operating in different revenue (e.g., as-a-service) and cost (e.g., asset-light) structures.
2. We have a competency deficit in how to apply new technologies and use data to run our core business better.
3. Our most respected managers and experts are healthily skeptical to change, since the current ways of working have served us well for decades.
4. Our most senior decision-makers behave in a protective and risk-averse manner, since they don’t have empirical comfort with the risk profile of new technology introductions.

Does any of this ring a bell? This isn’t the first-time organizations consider new technology. Remember BPR (Business Process Re-engineering), EPR, Lean?

To address these challenges, I would suggest the below four “no-regret” C-Level responsibilities:

1. SET A RELEVANT DIRECTION:

Often the case for change is defined by a combination of:

1. what we’re not doing (e.g., "we must simplify our ways of working"),
2. capabilities we don’t have (e.g., "we must all grow our digital skills"), and/or
3. what will happen if we don’t act (e.g., "we must defend against the Übers of the world").

I won’t deny the narrative of crisis is effective. We are biologically wired to recognize and respond to danger (known in psychology as the "negativity bias"). However, such narrative does little in terms of providing a direction. It merely talks about moving away from something. A truly effective narrative provides

• a sense of urgency (an emotional bond to a need to act)
• a clear direction (ideally a visualized outcome) as well as
• a sense of where the journey must start (a plausible, reasonable plan).

It’s a no-regret C-Level responsibility to develop such a narrative.

2. BUILD BUSINESS LINE CAPABILITIES:

Business-line leaders are the ultimate gatekeepers of success: They recognize, pursue and scale new and useful technology solutions across their current operations; They commit to associated revenue and cost improvements; They execute on people and product decisions to deliver. It’s reasonable to expect they’ll think twice before jumping on the next digital buzz word pushed from the center.

They need new talent. Specifically, people who ask questions like "What’s causing most equipment problems for you today?" followed by "Hey, what if we tried using this data set to detect those problems before they happen?". Differently put, to empower the business lines to self-discover a portfolio of useful and feasible initiatives. Such talent is scarce and likely difficult to attract using existing business divisional brand and employee promise. It is a clear C-Level responsibility to help supply such talent.

3. FORGE AN ECOSYSTEM:

Building technologies in-house is unlikely a rational choice. 25 years ago, if your team knew a handful of technologies (like in my case: Visual Basic, C++, and SQL), you’d have the skills you need for years. In 2018, on GitHub alone, 30 million developers made 1.1 billion contributions to 100 million code repositories. Today, enterprise-class solutions are built and maintained by picking the right technologies and stitching them together. Unless you’re in the core business of developing software, you’re better off staying on top of business problems you want to solve, and then working with professional partners to help you figure out which technologies to use and stitch them together for you.

It’s a C-Level responsibility to develop and evolve these partnerships with all its legal, commercial and architectural implications.

4. ENCOURAGE EXPERIMENTATION:

Many leaders still stick to myths like "becoming digital is a priority" or "data is our new competitive advantage". Simple truth is that "digital" and "data" will do you no good unless they support people being more productive in their jobs. Try thinking about data as an input factor (like wood) and digital as a toolset for processing data (like cutters and fasteners). Unless people tell you they’d be more productive sitting on oak chairs, there’s no telling whether you have enough of the right wood or the appropriate tools. Silly analogy? Business reality is even worse - people happily throw available tools at available data sets hoping to find needles in haystacks. Here’s the catch-22 - You can’t know if you have sufficient data to create a useful solution, until you’ve tried. Particularly for data science because the outcome is probabilistic by nature.

It’s a C-Level responsibility to do whatever it takes to foster a culture of fast experimentation and learning across all business lines.

WHO SHOULD OWN THESE RESPONSIBILITIES?

To keep it simple, you might need the Chief Strategy Officer / Head of Business Development to develop that narrative, your HR Officer to fix the talent, your CIO to build the ecosystem, and hire a bunch of consultants to traverse your business lines and drive experimental use case development. Done! But there’s a catch: Your CEO needs to set aside two days per week to lead this effort across your C-Suite. Most CEOs, though, lack either the bandwidth or the capability to take this role. They need someone to quarterback it: Behold a CDO with a clear focus.

CONCLUSION

CDOs started emerging in the shape of E-Commerce directors at the turn of the century to help bridge C-Level competency gap on all things "Internet". Today, as much as two thirds of all organizations have at least one CDO. The role of a CDO can be broadly described as "Helping us go Digital and Data Enabled" and hence leaves much room for interpretation. Some critics prophesize we’ll see the end of the CDO era within the next 5 years. Industrial companies are still in the early days of data enabling their business operations. I suggest there are at least four critical C-Level priorities to focus on, and that a CDO type mandate can be a good way to ensure that focus. In fact, the most important role of a CDO, is to foster and enable a culture of rapid experimentation within the business lines.