Facebook
Twitter
LinkedIn

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.

You have the training.
Now you need the job.

Unlock your potential with our new course: ‘How to Build an Agile Resume’. Dive into impactful lessons, gain exclusive insights, and join our Launch Party!

Comments

Leave a Comment

Related Posts

Responding to Change over Following a Plan

Explore the Agile value of Responding to Change over Following a Plan, and learn how to adapt quickly in a
April 18, 2024
Chris Sims

Working Product over Comprehensive Documentation

Prioritize working product over comprehensive documentation to create solutions that solve real human problems.
April 11, 2024
Corey Stewart
Tombstone with Agile written on the stone

Agile is Dead

Oh, the melodramatic eulogies for Agile, with Scrum Masters laid off and Product Owners disappearing into the sunset! “Agile is

April 5, 2024
The Agile Curmudgeon

Customer Collaboration over Contract Negotiation

When businesses and clients get too caught up in contract details, they lose focus on what’s important in real-world projects

April 4, 2024
Chris Sims

CAVU’s Sprint Planning Toolkit

Today, I’ll walk you through how to leverage our free Sprint Planning Toolkit to optimize your team’s performance and ensure
April 3, 2024
Chris Sims

5 Ways to Encourage Your Team

Unlock team potential with practical Agile methods for Scrum Masters to motivate and support their teams towards success. #AgileGrowth”
March 13, 2024
Chris Sims

Elevate Your Agility

Subscribe to our Blogs
Select the coaching guidance you would like in your inbox.
Scroll to Top