For a long time, we’ve heard that companies need to be innovative in order to keep up with the rapid pace of change in the 21st century. It’s great advice, but while we all understand a general definition of innovation, we struggle to apply it. How do I be innovative? If I decide today to be innovative, what do I put on my to-do list for tomorrow?
In order to help, we’ll try to lay out what innovation means in a simple, practical way. We’ll discuss how innovation happens (which may surprise you). And we’ll discuss a process for practical innovation programs. Our goal is to demystify the process of innovation so that it is less intimidating, and you have a better chance of successful innovation practices in your company and in your life. You’ll probably find a way to add something to your tasks to make a start.
Definition of innovation – a different, presumably better, idea that has a practical implementation. For simplicity, we’ll distinguish an innovation (which has an implementation in a process or product) from an idea (which doesn’t).
Often innovation processes are invisible while they are happening. If the innovation is important enough, someone may publish a retrospective account of how the innovation occurred. Academic science is an area with greater, although certainly not complete, transparency. Not surprisingly, innovation in science has been studied by academics.
Innovation in Science
Kuhn shows us that science moves episodically, with big changes occurring occasionally (and seemingly quickly) which are followed by stretches of marginal improvements to existing ideas. He refers to ‘paradigm shifts’ to describe these big, episodic changes. The marginal changes are a consolidation, extension, or refinement of the new paradigm.
In a less-rigorous view, I recall reading ‘Great Minds in Management’, which explored innovations in the science of management. Jay Barney’s resource-based view of the firm was considered. I recall that he talked about the difficulty of popularizing a paradigm shift. Creating new theory is knowledge work, resulting in a new description or viewpoint on our understanding of the world. But this is not the only innovation we can see.
Innovation as engineering – the physical product is the key
Engineering is the application of science, math, and technology to solve problems. Typically, engineers develop specific applications of a generally understood science. A civil engineer builds a bridge to suit a particular application, say crossing water of a specific depth over a specific distance. The idea of a bridge is not new, nor are the components of the specific application. Nevertheless, a bridge design for the Snake River Canyon would not work for the San Francisco Bay.
On the other hand, sometimes engineering is used to solve unique problems under a tight set of constraints. If you’ve seen movies like Apollo 13, or the Martian, you’ve seen accounts of applied engineering. How can the materials at hand be used to achieve a desired result?
In either case, the problem contains some new constraints causing previously developed solutions to be inapplicable. Either the bridge is longer, the water deeper, etc. or the typical materials for a solution are not available. In this sense, a new solution must be developed because the problem is different, in some way.
Sometimes a solution to a slightly different problem exposes a significant innovation.
An interesting aspect of the Apollo 13 kind of engineering emerges. In these cases, the existence of a physical product is a significant value driver. It didn’t matter that a perfectly useful solution existed in another place; that solution couldn’t be delivered to where it was needed. Let’s look at the implications of relaxing that constraint.
Innovation in Software Development
Software is perhaps the most intangible product that humankind has invented. While software can change physical reality (cause oil to flow through a pipeline, for example), many if not most instances of software exist to collect, manipulate, and deliver information, not to change the physical world. Since there is often no physical reality to software or its execution, solutions can be transferred and implemented very easily. Therefore, existing solutions can be, and often are, copied verbatim.
(This is not to say that product designs are hard to transmit and/or copy. However, in most engineering problems, the design is only a small part of the solution. A physical implementation of the design is what matters.)
Another difference in the non-physicality of software: Many previous innovations (solutions to software problems) are now embedded into libraries. As an example, most languages have print libraries as part of the language. It is no longer necessary to send low level print language to a printer. The embeddedness of such solutions (formally referred to ‘encapsulation’) is very different from other kinds of engineering.
Finally, since there is no physical implementation, experimentation with programming is very easy, and fairly low-cost. A few minutes of typing will typically implement a solution and produce a result. The programmer evaluates the result to see if it solves the problem (or part of it).
In this sense, when a programmer faces a problem, the first step is to see if the problem has been solved somewhere by someone. Once the problem is solved, code is often posted for the benefit of the community (and the reputation of the developer). Is there a function in some library somewhere that will do what needs doing? Has some other programmer posted a solution where Google can find it? Have any of my colleagues faced a similar problem?
If so, the implementation of that solution is typically fairly trivial. There are no girders to deliver and no welding to be done. No holes to be dug and filled with concrete. Copy and paste, tweak some areas to match the particular interface, and use the result.
If not, the programmer is solving a problem that (as far as can be known) has never been solved. There is no formula or model for solving it, such as there usually is in physical engineering. In this sense, programming is a particularly innovative area of endeavor.
At this point, aided by the ease of experimentation, many (most?) programmers fall into a particular pattern – trial and error. They think about getting something closer to what they’re looking for, narrowing the gap between where they are and where they want to be. Then they look for another step closer. Lots of dead ends and ‘start overs’.
But, even outside of programming, innovation often devolves into this kind of effort. It relies on imagination, resourcefulness, and determination. This is exemplified by the scene in Apollo 13 where Ken Mattingly sits in the simulator for hours trying to find the right sequence to restart the re-entry module.
The takeaway here is: if you want to innovate, as an engineer, a programmer, an entrepreneur, or an employee, bring your patience. At the end of the day, you’ll likely just need tenacity. Make sure your goal is worth the trouble.
