**4.1. Prescriptions**

Christensen and Raynor [1] advocate the building of a "Disruptive Growth Engine" founded on the following principles:

*4.2.1. Getting past the engineer's fallacy*

business, economics, and engineering.

*4.2.2. Overcoming the innovator's impatience*

this means for me/my team/my function."

**4.3. Reframing the question**

cessfully innovate inside:

need to sustain value growth?

ticipate on the journey?

**4.4. Evolution and engagement**

ance, and collective endeavor.

The language used to describe the challenges we are discussing often betrays the mindset of the engineer. We are introduced to "engines," "systems," "transformations," "cycles," and "capabilities." These are mechanistic things that can be designed, controlled, taken apart, repaired, and reconfigured. Yet, organizations are not machines; they are human organisms. Our understanding might be better served by insights from bioscience, psychology, and behavioral science rather than

Innovation Inside

13

http://dx.doi.org/10.5772/intechopen.74090

It is something of a cliché to say that organizations stand or fall because of the people who work in them. Organizations are driven by human motivation, energy, ingenuity, persever-

They cannot be "transformed" from one state to another at the flick of switch; they cannot be restructured or reconfigured like some MBA version of Frankenstein's monster. Rather, sustainable organizations tend to evolve through thousands of small, individual changes, one day at a time.

Innovation leaders are naturally impatient and want to get on to the next thing. They can see it. Why cannot everybody else? Yet, within any large, established organization that is trying to do something different, the change will only come from many people doing many things differently. Innovation leaders sometimes have a tendency to go around telling people what it is they need to do differently, taking it as read that changes are self-evident, desirable, and achievable.

There are two important counters to this way of thinking. First, the complexity of organizational change means that it is near impossible to figure out in advance the full implications of a significant innovation. They are not self-evident. We need a mechanism to work out "what

Second, there is a human challenge to motivate and persuade. Nobody likes to be told what to do differently without also understanding "what's in it for me." Yet, many organizations are in such a hurry that they persuade themselves there is not time to engage and align their people.

We can sum this up in the form of two further questions we need to address in order to suc-

**1.** How do we **evolve** our organization and get in shape to execute the innovations that we

**2.** How do we **engage** people across the organization so that they will enthusiastically par-

Our response to these questions contains two discrete, complementary elements:


Govindarajan and Trimble [4] also argue for the purposeful separation of innovation initiatives from ongoing operations. They also argue that there is a gap between "committing to an innovative idea" and "making innovation happen," with a need to reassess the approach to organizing and planning in the same way that one would ordinarily do between strategy and execution.

Their recommendation is, for each innovation initiative, to build a team with a custom organizational model and a plan that is revised only through a rigorous learning process. The custom team works in parallel with ongoing operations, and the plan evolves through a series of disciplined "test and learn" experiments.

Outram [5] advocates three things behind organizing for a successful delivery of strategy (for which we read "organizational innovation" in this context):


We would argue that these are sensible suggestions that are necessary but not sufficient. It is not enough to reach a point where a small team of smart people has done most of the thinking and then expect to be able to roll out/train the troops, with the assumption common in management thinking that it is simply a question of deterministic "execution."
