What’s on the mind of CTOs? Data, agility, footprint

In a fast-evolving environment, CTOs across industries and locations are focusing on the same three interconnected themes.

In a fast-evolving environment, CTOs across industries and geographies are focusing on the same three interconnected themes.

Over the past year, in my role as leader of McKinsey's Global Product Development Practice, I have had the privilege of meeting over 50 chief technology officers and heads of R&D across industries and geographies. While each meeting was unique and specific to these executives and their companies, some common themes and questions emerged. In this short article, rather than trying to answer all the questions they raised, I would like to share their themes and thought processes as a basis for wider discussion and sharing of learnings.

The three big themes were: data, agility, and footprint.


This did not come as a surprise. Digitization is a hot topic everywhere, and the relevance of data is a strategic consequence of this focus. The core question on CTOs' minds is: How can I ever earn a return on data? Most of these executives are from industries with no history of monetizing data. Many confessed that "software is something that our customers still expect for free on top of the product." Nearly all said their strategy talks about the move "from today's product to tomorrow's solution."

However, in practice, neither customers nor the companies are prepared to let go of traditional business, as the bulk of margins is still associated with classic product sales. At the same time, CTOs are keenly aware of the threat of external disruptors, who lack the burden of existing assets and commitments, making it easier for them to occupy critical control points and interrupt customer interfaces. Moreover, these disruptors operate according to a different business logic, focusing on penetration and market share rather than profitability—a game that is nearly impossible for incumbents to play.

Most CTOs told me that, as a defensive move, they have begun to systematically collect all data by default, fully aware of potential future conflict lines with their customers, and in some cases, their suppliers. Many are exploring dozens of use cases for data in parallel pilot tests, trying to understand the dynamics and value of the data in new business models. Some have concluded that industry-level responses are needed. Examples include defining data standards and interfaces, or even pooling data to enhance customer benefit for all. Thinking through such coopetition models is incredibly hard, requiring careful examination of both economic and legal issues. Nevertheless, a few models exist, such as the joint Nokia HERE map acquisition by the German automotive OEMs Audi, BMW, and Daimler.

Even with successful action, winning data business models remain scarce and sought after. Few executives feel confident, often pointing to a set of "add-on options' (many of which are still associated with dedicated hardware or software), and smart positioning in the emerging ecosystem in their industry.


This topic becomes more and more pressing the larger the institution. It stems from the realization that the complex checks and balances in large R&D systems protect the quality of outcomes, along with the multiple objectives set by stakeholders and interest groups in the organization. The problem is that these checks also slow the organization down by overcoordinating and overcomplexifying. As a result, everyone in the organization is working incredibly hard—even unsustainably at some critical interfaces—while management realizes that overall output is still too slow.

Worse, senior managers are often the only ones with an overall perspective, and thus are increasingly getting pulled in by teams that are "delegating up." Economies of scale that show up on paper are leading to delays and costly firefighting in practice. At the same time, nifty startups or emerging-market competitors with highly dedicated but small teams of engineers are delivering competitive products in record time.

In many cases, frustrated CTOs have tried to emulate these startups by carving out small, dedicated project teams for breakthrough projects (the classic skunkworks approach pioneered by Lockheed Martin). While often successful in single cases, this approach does not resolve the principle issues in the bulk of the portfolio. Companies are placing a lot of hope in agile development approaches (with variants known as "scrum," "lean," or even "holocracy"). These approaches copy successful principles from modern software development and organization theory. Common to all of them is granting far greater empowerment and accountability to dedicated teams that work in defined "sprints" or "beats" to complete a specific element of the software rapidly.

As CTOs progress with this approach, they learn two important lessons. First, moving into agile development often reduces the need for "traditional" middle management, as control is inevitably released to enable greater agility. This triggers a significant change management task, thus transforming the middle manager's function. Second, operating successfully in a network of autonomous teams requires major improvement in system architecture and modularity to limit friction at team interfaces. In fact, the few CTOs that describe themselves as advanced on this course often spend the bulk of their time guiding and challenging system engineering on the long-term stability and evolution of the fundamental product architectures. Similar to modern IT management, a two-speed R&D function is emerging, with a stable core architecture, and highly flexible cells built on top of it. Many CTOs are hoping to structure these cells around product features, a trend that we at McKinsey recently described in our white paper on "Feature-based development."


This came as a surprise. The original discussion on the globalization and structure of an effective R&D footprint peaked around 2005, when offshoring engineering to India and China was top of mind for many CTOs. Yet the question of how to set up and manage a global R&D network is back, though for different reasons: long gone is the motivation to simply reduce cost per engineer. CTOs are now trying to improve effectiveness by consolidating their organizations and orienting them toward future technology trends and talent. In some cases, discussions on revisiting the footprint are spurred by fears of geopolitical risks and regulation.

CTOs who are pondering such transitions, or already undergoing them, all noted that success requires that organizations first map their existing and required skills. Inevitably, this kind of transparency on the status quo often raises questions about current resource management and deployment, in particular in R&D footprints that grew opportunistically or through acquisitions. In addition, many CTOs worry about protecting IP and critical skills when they move engineering tasks to some countries. Many find it helpful to think through archetype structures such as centers of competence or excellence, or service centers, when defining the critical mission statements for each location.

Another challenge to revising footprints arises in the actual transition, especially if some sites perceive themselves as losers in the process. CTOs said they have learned that transferring skills takes time and commitment, and is rarely successful without the leadership of experienced expats. That said, they have also found that the reaction from existing sites is often less dramatic than they expected. It seems that the pride of delivering a great product trumps disappointment over perceived or real changes to the existing structure.

* * *

Data. Agility. Footprint. The environment for CTOs and leaders of R&D organizations has rarely been so demanding or indeed so exciting. I look forward to your personal reflections and thoughts

About the authors: Florian Weig is a senior partner in McKinsey’s Munich office.