Operations Practice

The present-focused, future-

ready R&D organization
There’s no one right way to organize R&D. But a set of core design princi-
ples can provide the flexibility R&D organizations need to outpace com-
petitors.

by Anne Hidma, Sebastian Küchler, and Vendla Sandström

© Getty Images

July 2020
 Across engineered industries, the explosion in organization, with inevitable trade–offs. Today’s
software has increased product complexity by an R&D teams don’t have the luxury of following a
order of magnitude. Along with rapidly evolving sequential, piece-by-piece approach in which
technologies, fast-changing consumer preferences, finished, designed components are handed off
accelerated product cycles, and the practical to testing at the end. Moreover, the teams need
realities of globalized operations and markets, R&D to be insulated from the external and internal
departments are under unprecedented strain. As the disruptions that the broader organization
product variation grows and product portfolios experiences, which today come with greater
expand, updating existing products compounds the frequency.
already heavy load R&D organizations bear.
As they’ve grown organically, many R&D
Yet amid these 21st-century challenges, R&D organizations continue to operate with the same
units are still following 20th-century models of structures and processes they’ve used for years.
organization—models not designed for today’s Despite (or perhaps because of) the increasing
need for speed and the expanding web of inadequacy of those structures and processes,
interdependencies among all of the moving parts. organizations don’t follow them consistently.
The traditional component-based approach to R&D Pet projects are often hard to kill, even long
is no longer sensible in an era when digital and after their diminished promise becomes
electronic systems are so thoroughly integrated apparent. And because research effectiveness
with hardware. Still many companies struggle to is hard to measure—and companies often don’t
shift toward an approach that focuses more on understand R&D costs or ways of working—the
the function the customer wants, rather than the black-box image persists without challenge.
components that make the desired function work.
Thus, adhering to an existing structure isn’t
There is no one right way to organize R&D. But enough: the shifting demands, the sheer
there are certain fundamentals that can help R&D volume of work and the growing complexity
organizations, regardless of industry, act more (much of it the result of software integration)
responsively and meet the burgeoning challenges make it incumbent on R&D organizations to
they face today. From our work with clients and reappraise their design. Instead, they can create
our extensive research, we’ve distilled a set of new mechanisms to provide the coordination,
core design principles for R&D organizations transparency, governance, and risk protection
and identified the important ones. By following R&D needs in the digital era.
these principles, companies can help their R&D
organization serve as engines of innovation
for outpacing competitors. And they can foster A set of winning design principles
the agility organizations need in supporting In the ideal R&D organization, responsibilities
collaboration among remote, distributed teams—as are clearly established, and interfaces between
has become more important than ever in response and among teams (internal and external) are
to unpredictable external events. seamless and transparent. These requirements,
although not new, have become even more
important of late, particularly when more teams
A growing mismatch between design are working remotely. R&D organizations
and function that fulfill them can better meet further
Determining the right structure for the R&D requirements—managing complexity actively
organization has never been easy. The division and efficiently while staying focused on the
of responsibility is a balancing act between the future, and also maintaining the tools and
project-management organization and the R&D line capabilities for adapting to change.

2 The present-focused, future-ready R&D organization

Clearly delineate responsibilities for that coordination occurs only late in design,
systems and end-to-end work perhaps even the final testing phase, by which
Historically, the R&D function has been organized point addressing problems becomes expensive
according to components or location, which has and time-consuming. R&D organizations are
the effect of creating silos. Product properties are more effective when they shift their orientation
defined at the start of the development process, from components to user function, while keeping
without being analyzed according to larger internal platform development stable to ensure a core of
systems or user functions. Little attention is given commonly used modules.
to thinking in terms of the overarching goals
customers want to achieve, or to the growing With such a shift, assigning end-to-end
interdependencies as software and digital responsibility for functionality has become
functions have pervaded almost every engineered imperative. Companies can assign responsibility
product. for the complete product, as well as for the
individual system layers, under the “V” model
Many of the complications R&D organizations shown in Exhibit 1, which imposes oversight as
encounter today are the result of organizational ideas progress from concept through to market
interfaces that don’t match the product, along release, series development, and finally upgrades.
with a lack of transparency between groups. Take,
for example, a feature such as lane assistance The process moves from left to right. Under
for vehicles. Developing further advances in this “Conception,” individual systems and their
function depends on a high level of coordination associated software are defined to fit customer
among teams developing steering systems, brake demands and budget. Through early testing in
systems, and electrical systems. But too often the development process, issues and challenges

Exhibit 1:
TheThe V model
V model divides
divides developmentresponsibilities
development responsibilitiesby
bysystem
system layers,
layers, showing
showing
iterations
iterations andand handoffs.
handoffs.

Conception Testing

Requirement Acceptance
design test
Requirements/
user stories
System System
design test

Architecture Integration
design Architecture test
and integration
Verification phases Validation phases
Module
Unit test
design

Development/coding

The present-focused, future-ready R&D organization 3

 become apparent early on. The right side of the
duplication of similar work are both important as
V comprises testing and integration, which are
well. Furthermore, to be cost-effective, location
conducted along the system layers. By breaking a
design can identify best-cost country sourcing
product’s properties into requirements for systems
for repetitive tasks, keeping in mind end-to-end
and functions, the activities become transparent to
responsibilities.
everyone involved in development.
Dividing projects up among sites is usually less
This approach enables iterative handshakes—
ideal, as people who work together in the same
more frequent interactions between concept
place tend to work more efficiently: earlier research
owners and developers. Teams work together to
found that with each additional development site
translate properties into functional requirements.
for a given software product, productivity fell by
The approach also establishes dedicated
about 14 percent (Exhibit 2.) Just the difference
responsibilities for complex functions and
between one site and three sites amounts to a 37
keeps the development process transparent. To
percent decline in productivity.
coordinate and manage the interaction points,
automotive companies tend to introduce central
Minimizing the number of handovers between
units that manage the whole integration process
sites—and making those that remain as smooth
along the different development steps. These
as possible—also helps. Distance between sites is
departments can be seen as a “stable backbone”
not what matters; without the right management
within a dynamic development process, which
practices, a site across the city can seem as distant
helps improve planning for milestones and
to employees as one clear across the country. But
facilitates early failure detection. One machinery
virtual teams can be as efficient as co-located
company, for example, set up quarterly integration
teams, as long as the tools supporting the virtual
meetings to align on priorities; the one to two days
work are utilized properly, communication is
team members spend planning together gets them
adapted accordingly, and everyone can participate
aligned for the next quarter’s work.
on an equal basis.

Perhaps the biggest benefit to assigning end-to-

R&D leaders can consider future roles and
end responsibility is that it enables R&D to manage
competencies when thinking about the physical
the interfaces and different development cycles
design of the department. Where should the
between hardware and software development.
development of next-generation products start?
Functionality owners coordinate the development
How could a transition to new products be built
of complex and interdependent components
for sites currently focused on legacy products?
and features, creating technical guidelines and
How will cost and availability figure into the overall
specifications that support consistency. They
network structure? The answers form a long-term
effectively safeguard the implementation and
site strategy that can help avert a talent crunch.
validate that the solution fulfills its requirements
over its entire lifecycle.
The right footprint model also builds in a detailed
understanding of local requirements, such as
interactions with suppliers, local regulations,
Keep functional interfaces across work and internally, the interdependencies with other
sites to a minimum departments or components. The sophistication
Companies can most effectively conceive of the design work, and the degree of conceptual
of interfaces in terms of R&D’s geographic work that will be done in a particular location, will
footprint—a balance taking into account which inform the kind of competencies and technologies
activities are performed where, and how the that will be needed. For example, one white-goods
locations must interact. Minimizing functional manufacturer carried out almost all development
interfaces across multiple sites and avoiding in its home market, later building a few local

4 The present-focused, future-ready R&D organization

 Exhibit 2:
Fewerdevelopment
Fewer development sites
sites means
means higher
higher productivity.
productivity.

Productivity decreases by ~14% per extra development site added1

Complexity units per person-week, indexed

-14% per site

100
76
63 57 52 48

1 site 2 sites 3 sites 4 sites 5 sites 6 sites

1
Based on McKinsey Numetrics database

development centers in key markets to help adjust integration problems and delays are almost
the products for local preferences, such as for inevitable.
refrigerator and freezer sizes, configurations, and
color schemes. As essential as synchronizing development may
be, it isn’t easy. In automotive, for example, map
software generally takes about a year to develop,
Synchronize software and hardware with frequent updates, while apps or innovative
development vehicle-control features (such as autopilot) may
Complexity in all its forms has increased markedly— be updated monthly, with ongoing development
product variations alone have exploded over the and improvement. Contrast these cycle times with
past two to three decades, driven largely by the rise the hardware that runs navigation systems (which
of embedded software and digital capabilities. take two to three years to design and build), vehicle
platforms (about seven years in the making) and
But R&D protocols often fail to account for the basic vehicle components, such as heating systems
unique challenges of managing the development of and airbags—mature components that typically have
integrated software and hardware. Software and a 10-year lifespan.
hardware development follow different development
cycles and require different approaches to project With such wide disparities in cycle times,
steering. And when digital features or components transparency becomes crucial. The lack of it is a
aren’t explicitly considered in milestone planning, problem not only in concept development, but in

The present-focused, future-ready R&D organization 5

 delaying product launches as well. For complex them in the R&D organization, but keep them
functions, such as lane assistance, R&D units may separate; or integrate them fully into the core
have limited ability to measure how mature the R&D organization (Exhibit 3).
product really is. When changes are made, teams
may therefore fail to assess the implications on Segregating the current and new technologies
other features currently in development. Beyond has its advantages. Unfettered by standard
cost overruns, delays, and risks to product processes, separated units are free to realize
integrity, poorly managed complexity invariably their full potential. The R&D organization
leads to finger-pointing among system teams as keeps budgets separate and shields the new
well as conflict between R&D and the project- technology from the noise of existing projects.
management team.
But this option can be a hard sell to
R&D organizations have two options for managing management, as creating a new unit can be
the complexities of synching software and costly, labor-intensive, and harder to absorb
hardware development. into the existing structure. Beyond the break-
in time to adapt to existing products and
— Embedding software development within processes, segregation also limits the broader
existing departments. This approach promotes organization’s ability to transfer capabilities
integrated development—but in practice, and knowledge, particularly given that cutting-
processes are often designed from a hardware edge technologies call for special (at times rare)
point of view, and software complexity is not expertise and training time for employees.
managed effectively.
Short of total separation, there are essentially
— Keeping development separate but two ways to include new technology
coordinated. With this arrangement, individual development within the R&D organization.
technology components don’t get short Integrating new technologies fully into the
shrift. The onus is on leaders to establish existing organization helps transfer knowledge,
synchronization points to identify potential and lets the new part of the organization tap
conflicts that would require escalation to into existing capabilities and processes, all of
senior management. which helps in reaching scale faster. However,
in this arrangement, there are risks—new
The approach to take is generally determined technologies could be prematurely quashed by
by the nature of the product, as well as the senior management, or if developed according
organization’s experience with software— to current methodologies, could yield less-than-
bearing in mind that complexity will likely grow. optimal results.
Increasingly, services are developed not only
within the engineering department but also Most often, the best bet is a happy medium,
within IT, creating still more interfaces and in which new technologies are assigned to a
responsibilities, with implications for organization separate team but explored within the current
design. R&D organization (see sidebar, “An R&D
makeover to sustain market leadership”).

Strike a balance between old and new The right approach is also a function of the
technologies situation and the culture. Consider the electric
When it comes to developing new technologies, powertrain in the automotive industry—the
R&D managers have three choices: segregate different manufacturers offer a sample of all of
them completely in a separate unit; include the archetypes.

6 The present-focused, future-ready R&D organization

 Exhibit 3:
R&D departments
R&D departmentscan
canchoose
choose among
among three organizationalarchetypes
three organizational archetypesfor
for
new-technology
new-technologyintegration.
integration.

Classic R&D organization

R&D New Tech

Ring-fence new technologies in separate unit (with separate budgets)

Separation allows for full focus on new-technology development
Easier to segregate because the new technologies are nearly independent of the current ones

Segregate the new

R&D

Nucleus for new technologies is located within existing R&D organization

New technologies are already linked to existing processes and systems because they‘re in the same organization
Facilitates early knowledge transfer

Integrated new and old

R&D

Development of existing and new technologies is fully integrated

Existing processes and tools can be fully leveraged
The new technologies must be important or have high potential in order to be relevant in existing organization

The present-focused, future-ready R&D organization 7

 An R&D makeover to sustain market leadership

A global production-equipment manufac- — System functions, which handled Cutting complexity

turer had long viewed its R&D organization the functionalities that met system As a first step in redesigning the R&D orga-
as a crucial source of competitive advan- specs and customer requirements, nization, R&D leaders made system function
tage. But the company’s rapid growth and such as for productivity and machine leaders responsible for tangible and
increasingly complex product portfolio precision. testable machine modules. System leaders’
meant that more products were being de- reports were given responsibility for the
veloped in parallel. That led to even greater — Engineering functions, respective submodules. In that way, every
specialization among engineers and more encompassing specialties such as production module and submodule would
technical interdependencies across mod- electronics, mechanics, software, have a clear owner with end-to-end respon-
ules. As the number of engineers and man- and environmental controls. sibility, from new-product introduction to
agement layers grew, so did the number These functions were required for third-line field-service support. Whereas
and complexity of interfaces, threatening developing the system modules and before, each engineer worked on multiple
the company’s rapid growth. the system architecture needed products, under the new system each now
for the integrity of the assembled works on only one business line and handles
Historically, R&D groups had been orga- machine. only one submodule at a time (Exhibit).
nized in two types of departments.

Exhibit:
Redesigning
Redesigning R&D
R&D clarifies
clarifies ownership,
ownership, enhancesenhances transparency,
transparency, and reduces
and reduces interfaces.
interfaces.
Reporting line
Head of R&D Operational steering

Engineering cluster Integration

System module clusters
(eg, software)

Architecture

Module Module
Architecture Engineering
Business line 1 Business line 2

Engineering
group

Engineering

8 The present-focused, future-ready R&D organization

System-function departments are now design and standards (the left side of the V and governed through an annual planning
primarily business-line dedicated. Each in Exhibit 1 in the main text) and for setting cycle.
system function has a central architecture guardrails for module design and develop-
team that promotes commonality in the ment. This structure also ensures integrity The stable, multidisciplinary teams that
system modules’ roadmaps and the max- in the final product. characterize the new design have created
imum reuse of module elements among a solid foundation for piloting and scal-
business lines. ing agile ways of working in the product
Responsive and future-ready development teams. Since the launch of
Engineering-function teams (such as To maintain system integrity, shared the new organization, more than 2,000
software teams) are largely dedicated to platforms, and innovation- and knowl- engineers have migrated to agile methods.
modules or submodules. Leaders have edge-sharing across business lines, the But engineers aren’t the only ones work-
the authority to deliver their technical company established several central teams. ing in new ways. By forging and executing
roadmap with more stable, focused, and To manage competence (and continue the redesign as a team, R&D leaders have
experienced people. Within each engi- building needed skills), the organization developed adaptive muscle, with the ability
neering function is a central architecture developed a taxonomy of critical compe- to adjust their organization to fast-changing
department that’s responsible for system tencies, assigned to VPs and managers requirements and environments.

To be future-ready, adopt new ways on autonomous driving would include not only
of working software engineers but also hardware engineers
The traditional waterfall development model that from the steering, brake-system, and overall car-
some organizations still follow is so protracted design teams, as well as those working on user
that products can be obsolete by the time they interface design.
are released. Long development times become
impracticable when businesses factor in the out- To foster a future orientation within the R&D
of-sync cycle times of software and hardware function, companies can adopt certain design
components. In addition, a siloed and fragmented features and practices, in particular those
organizational structure makes it hard to respond structures that promote agility:
nimbly to new process requirements.
— A flat organization in which teams are granted
Fast-changing customer demands and full responsibility to design solutions. This
rapidly evolving technologies have increased creates a strong sense of ownership among
the premium for enterprises and their R&D individuals
organizations to be adaptable, flexible, and future-
oriented. And the coordination, integration, and — End-to-end, cross-functional teams whose
speed needed in R&D today call for new ways of talent is drawn from all the relevant and
working. These include agile methods that enable traditional R&D functions. Often, teams are
fast iterations and cross-functional, flexible supported by individuals outside of R&D,
teams that ensure that the concerns of all relevant such as marketing managers or customer
stakeholders—people from different functional representatives. Team membership is stable
units, as well as the different engineering teams, and changes only when projects are finished or
project managers, and customer representatives— strategic priorities change
are addressed. For example, a team working

The present-focused, future-ready R&D organization 9

 — Pools of experts (both internal and external) that struggle with how to reengineer their own work
support projects with the talent they need processes, often not knowing where to start. To
determine the right blueprint, it helps to step back
— Resource allocation that is flexible, shifting as and reflect on current performance and future
needs change needs by asking a few central questions:

— More co-location time for teams, wherever — Do we have a clear way of addressing the
possible complexity that comes from interfaces?

— Role descriptions and rewards that align with the — How are we handling interdependencies
new organizational structure and targets between systems? Is complexity increasing,
and if so, are we well set up for the future
These practices usually suggest that the company demands?
might consider changing certain roles in the
organization—particularly in light of the widespread — Do we have what it takes to adapt to a larger
need for more architects, as leaders are charged proportion of software development in our
with empowering teams to foster innovation R&D?
more than ever before. In fact, an automotive
manufacturer saw its leadership transformation — Are we sufficiently agile and flexible to adjust
as a driving force for putting in place its new R&D our focus based on changing demand? Could
organization. we handle more frequent changes in demand?

A further question we are hearing is: how does all of — How prepared are we for future technologies?
this work in a remote working environment? The bulk Do we have the right structure in place to
of these practices can be implemented in a digitally acquire and scale them?
enabled organization if co-location is not an option,
with priority for practical matters such ensuring — Do we have sufficiently clear roles, interfaces,
teams have sufficient bandwidth to connect as and end-to-end responsibilities within
often as needed. Clear roles and targets will be R&D between teams and sites and to other
especially important as well, as will an emphasis on departments?
empowering teams and individuals.
There is no master formula for making this shift—
nor could there be, given the differences across
industries and from organization to organization—
With ever-expanding product portfolios—from more but certain principles prevail. Abiding by the
product variation to additional software embedded principles outlined here can provide a blueprint
in engineered products—R&D organizations tell us needed for integration at the right points, and the
they are struggling to keep up pace. That makes the much-needed transparency across R&D. If R&D
shift from a traditional, component-based approach is the company’s engine of innovation, its own
to a functional all the more essential. transformation is more than a matter of securing
market share, it’s about being built for a fast-
Change isn’t easy for this traditionally black-box changing present in order to secure the future.
area of the organization. Engineers themselves

Anne Hidma is an associate partner in McKinsey’s Amsterdam office, where Vendla Sandström is a consultant,
and Sebastian Küchler is a partner in the Munich office.

Copyright © 2020 McKinsey & Company. All rights reserved.

10 The present-focused, future-ready R&D organization