Engineering transformation for a 4.0 world: Winning over the experts who make innovation happen

Executive summary

As the pace of business accelerates and innovation becomes paramount, companies need to update their strategies and processes to get new products off the drawing board and out into the market quickly. Yet the very people who perform the task of developing new products — engineers — can often be the most resistant to change. Because the work that engineers do is different from that of other corporate functions, transformation efforts aimed at their work must be rethought as well.

Rather than trying to win over the entire engineering function, however, senior management should focus on the critical subset of people who are most responsible for enacting changes. The engineering department generally requires the talents of three main types of engineers: (1) inventors, a small group of highly creative people who are difficult to control; (2) developers, the critical middle layer who know the most efficient ways to manage the innovation process and get the job done; and (3) execution experts, the largest group in an engineering function, who typically respond to traditional transformation measures. Although every company needs inventors to envision the impossible and execution experts to get the work done, the developers are actually the core group that should be the target of transformation efforts. The developers are the decision makers at critical points. As the experts who know what makes a product or process work, they have the ability to influence the outcome of any project, and they are unlikely to buy into a transformation unless they believe in its merits.

In addressing developers, companies need to adapt and complement traditional transformation measures. Specifically, we believe seven best practices are critical.

  1. Clarify beliefs and behaviors, using language and examples that developers will understand.
  2. Communicate future goals in terms of tangible improvements.
  3. Lay out a transformation path with specific milestones and direct business impact.
  4. Identify where the perceptions of senior managers differ from those of developers.
  5. Identify and capitalize on "moments that matter."
  6. If undesired beliefs or behaviors persist, use the full spectrum of measures in response.
  7. Hold specific events to change mind-sets.

Agile innovation

The way companies develop products and services has changed dramatically over the past decade. Innovation is now global, with offerings that are often designed through a network of in-country development centers, increasingly located in emerging markets. Yet as technology grows more and more sophisticated, there is less emphasis on outsourcing mass production and more on products and services that are tailored to meet local demands. They’re also far more complex, with a greater reliance on software and digital elements that feed data back to the customer or company to improve the overall experience. In addition, a fast-moving business environment means that new ideas need to get to the market more quickly.

To respond to these changes, many companies have tried spending more on R&D. Yet they are not likely to boost value simply by increasing spending, even if they churn out more products. A decade’s worth of detailed analyses by Strategy&, PwC’s strategy consulting practice, shows that there is no correlation between total R&D spending and any financial metric: revenue, profit margins, or (for public companies) shareholder returns.

The technological demands of the 21st century require, rather than just a boost in R&D, a transformation of the entire innovation process. Companies are shifting away from the traditional waterfall method of developing products and services, with a standardized and formal sequence of steps from conception to production. Instead, they’re favoring more agile approaches that capitalize on digital technology and allow them to upgrade designs in much faster cycles. This kind of change generally requires a transformation in the corporate culture so that the whole organization is structured around the open communication and rapid feedback that allow an agile innovation process. Yet PwC Strategy&’s annual Innovation 1000 studies have found that even among the most innovative companies, more than half admit that their culture is not in full alignment with their innovation strategy.

Furthermore, one of the most important elements of a culture of agile innovation is hidden in plain sight. No amount of investment in digitization and new strategies will help a company keep ahead of technological disruption unless the engineers believe that the changes in the innovation process are for the better. Winning them over, however, will require a transformation in the engineering function itself. Engineers expect proof that a new process will work across the board before they will embrace it, and without that evidence they can often be the most reluctant of anyone in the organization to change. In some cases, if they don’t believe in the value of a new strategy, they may even subconsciously sabotage it, out of the best possible intentions.

Why? It’s tempting to attribute this behavior to the stereotypical personality type of engineers. They are analytical, data-driven, and skeptical of disruptive change. They have built up their current level of expertise within an established system — skills, methods, empirical knowledge, and even the use of their own language and terminology — and take professional pride in it.

Because engineering work is so different, transformation efforts aimed at engineering functions must be different as well.

Yet there are also real reasons that the work engineers do makes them less willing than people in other roles to embrace transformation. In contrast to highly linear functions such as manufacturing or administration — where change is easier to implement — engineers need to consider a wider range of interrelated aspects, including product performance and cost, time-to-market, and regulatory approval, among others, all with a limited set of resources (including budget). Trial and error is an inherent and even essential part of the process. Product development happens across organizational boundaries, and one genius, or even a few with superlative skills, can make a big difference in the outcome.

Because engineering work is so different, transformation efforts aimed at engineering functions must be different as well. Rather than simply mandating a new strategy, senior management needs to address the culture of engineering functions, including mind-sets, behaviors, and values among engineers. It is difficult work, but it’s the only way to generate sustainable improvements in performance.

Three engineering profiles

The good news is that senior management doesn’t have to win over the entire engineering function. Instead, there are critical subsets of employees in the organization, each meriting its own level of attention during a transformation. Based on our experience, there are three typical profiles in an engineering organization. Although the demands of a particular job might partly determine which profile an engineer fits, smart managers will also channel engineers into job profiles that fit their individual temperament (Exhibit 1).

Exhibit 1: Three engineering profiles

Three engineering profiles

  • Inventor (less than 5 percent of engineering staff). People in the inventor profile seek the freedom to experiment in order to find new products and solutions. (The use or applicability of the idea is often secondary.) These people are treated as geniuses or mavericks, and they are few in number. They celebrate novelty and abhor constraints, and in general they are difficult to control and to reorient around a new strategy.
  • Developer (approximately 15 percent of engineering staff). In the middle are the developers. They typically combine known elements to create new solutions for a specific use or application, with preset constraints and a clear target outcome. The stereotypical developer is a tinkerer — a creative person who takes joy in getting a successful product to market. Developers tend to be good at networking, understanding trade-offs, and clarifying decisions.
  • Execution expert (as much as 80 percent of engineering staff). Holding the organization together at the base are execution experts, the biggest group in an engineering function. People in this profile — such as engineering factory operators — require explicit direction and have a strong belief in processes. In general, execution experts respond to traditional transformation measures, such as consistent communication, training on new skills, and incentive systems.

The right mind-set for developers

Developers are the linchpin in product development. They serve as an intermediary between the mad scientists (the inventors) and the process-oriented staff (the execution experts). They make key decisions at critical points in the process, and thus have significant clout — both formal and informal — in steering the process as it advances. For example, developers often have to find the right balance across a set of target parameters, including development time, product cost and quality, and regulatory constraints, among others. These parameters are interdependent, and often contradictory. Developers also have to set the right priorities, which requires good business sense and judgment regarding the feasibility of specific goals. They need to generate a consensus among stakeholders, and they frequently present options to the senior management of both the engineering function and the overall organization.

Ideally, the options should be transparent at these points, with the developer putting everything on the table, including alternatives that may spring from unconventional thinking. The discussions should happen at the right point in the process — neither too early (before sufficient information is available) nor too late (after resources have been committed and executives need to rush their thinking). And the discussions should include input from all relevant stakeholders.

This ideal scenario rarely materializes in the real world. Instead, many developers put their thumb on the scale at these points and steer the discussion toward an outcome that they believe would be best — often based on what worked best in the past. They are essentially sabotaging the new project, out of a mistaken belief that it will not work.

Seven keys to change

Because the engineers in the middle stratum have the ability to make or break a project, senior managers for both the engineering function and the overall company should focus specifically on developers when introducing a new innovation strategy and embarking on a cultural transformation. More specifically, they should create the right mind-set among developers, spurring them to embrace the new strategy rather than undercut it.

On a high level, many of the traditional and proven steps in a transformation do work in engineering, particularly for execution experts. These include an explicit rationale for the change, clear and consistent communication, the right incentives, and follow-through by management. However, in addressing developers, companies need to adapt and complement those measures. Specifically, we believe seven best practices are critical.

1. Clarify beliefs and behaviors, using language and examples that developers will understand. Frequently, developers have a very clear and deeply held set of beliefs, usually backed up by experiences and well-established ways of working that enabled them to deliver breakthrough innovations in the past. Yet these beliefs can limit their thinking and lead them to undermine new strategic initiatives. For example, they may cling to notions such as "We’ve always done it this way" or "That new approach will not work" or "It’s too late to change this now." Those underlying beliefs lead developers to take actions against a new initiative — at a minimum, preventing it from achieving its full potential; at worst, stopping it in its tracks entirely (Exhibit 2).

Exhibit 2: A case example of how developers think

A case example of how developers think

Instead, senior management needs to give developers the right set of beliefs, which enable and empower them to take specific actions to support an initiative. For example, believing that “there must be a better solution” will help developers challenge the status quo. When communicating these beliefs, engineering leaders — who typically have been in the developers’ shoes earlier in their careers — should use personal examples that show how a deviation from an established process or solution ultimately led to success.

2. Communicate future goals in terms of tangible improvements. Transformations work when developers have a very clear understanding of exactly what will change, and how. Senior management needs to lay out specific improvements in processes, new ways of solving problems, and new content, so that developers understand precisely how the organization will change — and how the new target state will be better.

In addition, senior management needs to give developers the skills they need to succeed. For example, if a company wants its engineers to work digitally, it needs to provide training programs on the new tools. This is more challenging in engineering than in other functions, such as manufacturing, where it is relatively easy to train operators in how to use a new piece of production equipment. In engineering, by contrast, new tools change the way people think and solve problems, so the training and development aspect needs to be more rigorous (and, typically, last longer).

3. Lay out a transformation path with specific milestones and direct business impact. A complex product takes years to develop and get to market. Strategic transformations will take just as long to deliver final results, meaning that management teams need to phase in their implementation. Senior management needs to specify which new behaviors and values will apply, to which new projects, and over what time period. It’s critical that companies create detailed time lines that translate the cultural shift into business objectives at clear milestones along the way, but also stay flexible in their transformation approach to adapt to specific needs of the organization. The more challenging the transformation objectives are, the more detailed and customized the transformation path needs to be.

4. Identify where the perceptions of senior managers differ from those of developers. Rather than simply handing down a one-way mandate from the leadership team to the engineering function, companies should solicit feedback on the plan from those tasked with implementing it. Getting this kind of feedback in advance of implementing the plan will help senior management identify trouble spots where the transformation may require adjustments or where the implementation will require more concerted effort, such as additional communication, special events, or one-on-one discussions and training.

It’s critical that companies create detailed time lines that translate the cultural shift into business objectives at clear milestones along the way.

Notably, the results of this exercise will almost certainly vary across sites, departments, and facilities in the engineering function, which adds another layer of complexity. For example, developers working on the electrical system in a complex product might be more open to digitization than their colleagues who are responsible for the mechanical properties, while the developers tasked with testing and validation might have an entirely different perception.

5. Identify and capitalize on "moments that matter." Developers — like all employees — look to leaders for guidance, and they are particularly attuned to any situations in which a leader’s actions do not line up with his or her words. In engineering organizations, this effect is even more pronounced, as executives have typically risen through an engineering career themselves. Moreover, some junctures during the process have a disproportionate impact on the outcome — and the organizational culture. At these moments, it is crucial that senior management serves as a role model.

For example, management may set a goal to develop lower-cost products. Twelve months later, when the developer presents prototypes of a low-cost version and a higher-cost version, this is a moment that matters. If executives balk at the low-cost version and change the objective, developers will — understandably — perceive that the original goal is no longer in place.

6. If undesired beliefs or behaviors persist, use the full spectrum of measures in response. Some developers will almost certainly require corrections and reinforcement along the way. There is a full suite of measures that senior management can use in these situations, tailored to the severity of the problem and the talent level of the individual. For example, if a developer gives a biased presentation — essentially arguing with half-truths — engineering leaders can choose from a variety of actions. These include issuing a sporting challenge ("Can you do better?"), sending the presentation back for a second try, criticizing it openly and in detail, investing time to mentor or coach the developer, and — in extreme cases — rotating the developer off the project.

7. Hold specific events to change mind-sets. In some cases, specially orchestrated events can have a dramatic effect in changing the culture and mind-set of developers. For example, senior management could stage a cross-functional "cost camp," a weeklong working session on how the company can develop alternative, cost-effective products and services.

To be effective, these events should happen at a key juncture in the development process, when they will lead to the greatest impact. The events should include both internal and external experts from different functions and departments to capture a range of perspectives. And, critically, senior management should create an environment in which people are rewarded for speaking candidly and challenging the status quo.


Transformation is an imperative within most engineering functions, yet it is difficult to implement. By identifying the critical subset of engineers, understanding their perspective, and tailoring a change initiative accordingly, companies can ensure that they create the right mind-set needed to innovative more effectively and get winning products and services to market more quickly. For the companies that get this right, there are clear financial rewards.