Five Barriers to Adopting Open Innovation and How to Overcome Them

(This piece was originally posted to the HeroX blog)

A friend of mine, an innovation consultant, likes to joke: “Innovation is simple…but not easy.” The same can be said about open innovation. Henry Chesbrough, who introduced the concept of open innovation in his classic 2003 book defined it as using external sources of knowledge and expertise to advance internal R&D. What can be simpler than that?

And yet, the adoption of open innovation has been far from seamless. Open innovation might look simple…but it’s not easy. Firms attempting to create formal open innovation programs face numerous barriers. And although many of these barriers are specific for each organization (remember Leo Tolstoy’s “Happy families are all alike; every unhappy family is unhappy in its own way”?), some barriers are quite ubiquitous. In this piece, I will review five common barriers to the adoption of open innovation and suggest approaches to overcoming them.

Treating open innovation as a “special” type of innovation

There is a reason why innovation is not easy. Modern organizations, especially corporations, are obsessed with execution. Predictability of outcomes and the precise match between planned and achieved results are the metrics against which organizations measure their performance and performance of their employees.

Innovation is different. By its very nature, innovation is highly unpredictable and relies on constant experimentation with most experiments ending up in failures. This unpredictability of outcomes makes innovation difficult to implement, especially when firms try to move their innovation targets beyond incremental improvements of existing products.

Open innovation adds a twist to this complexity by increasing the level of uncertainty: now, one needs to innovate with “strangers.” This fear of losing control over the innovation process forces firms to slow the adoption of bona fide open innovation tools like crowdsourcing and rely more on occasional surveys of their suppliers and business partners.

To overcome this barrier, open innovation must be closely aligned with the overall corporate innovation strategy. The simplest way to achieve that is to consider open innovation part of a single “innovation body.” One side if this body represents the innovation potential of the firm’s employees (internal innovation). The other side, open innovation, extends behind the corporate walls reaching out to the diverse pools of external talent.

In practical terms, in firms that just start using open innovation approaches, the open innovation team should reside within a larger corporate innovation unit. Sure, as the open innovation programs mature, the team will grow and at some point, become separate. But starting with a separate open innovation team from the very beginning is likely to set it up for failure.

Overcoming Not Invented Here Syndrome

As happens with the adoption of any new paradigm, successful adoption of open innovation requires cultural change – and cultural change is something that almost every organization has a difficulty to deal with.

A cultural problem most often associated with the adoption of open innovation is so-called Not Invented Here (NIH) Syndrome, a rejection by internal teams of ideas and solutions that did not originate within the firm. (It’s important to realize that NIH Syndrome affects internal innovation as well, but this is a topic for a separate conversation.)

There are no simple ways to overcome NIH Syndrome, and it takes time. Firms should promote a cultural shift from problem-solving to solution-finding. This approach postulates that employees are ultimately responsible for the project outcome. How this outcome is to be achieved – by solving the problem internally or by finding a suitable external solution – is of secondary consideration. What is important is how fast this outcome has been achieved and at which cost.

I strongly recommend reading the excellent article by Hila Lifshitz-Assaf, “Dismantling Knowledge Boundaries at NASA,” describing how NIH Syndrome was dealt with at the Space Life Science Directorate at NASA.

Mishandling Open Innovation Tools

Adding to the adoption problems is widespread confusion over available open innovation tools. Sure, some open innovation techniques, such as crowdsourcing, are not intuitive and need training and experience to use. But others, such as working with customers, suppliers, and partners, and running innovation competitions is something that many firms are quite familiar with.

Unfortunately, what is missing is a clear understanding that each specific open innovation tool is only good when applied to a matching innovation task. Some tasks are better performed using tools from a “co-creation” basket, others require crowdsourcing, and some may be achieved only with engaging startups.

It falls on academics, business writers, and innovation practitioners to educate innovation teams on the classification of open innovation tools and good practices of using them.

Fear of Revealing “Secrets”

A surprisingly common and persistent fear of adopting open innovation is the possibility of revealing proprietary information to competitors. One can often hear: “If we launch this open innovation initiative, our competitors will immediately know our strategy and our direction.” Perhaps, but don’t they already know your strategy and your direction?

In the era of digital transformation, the pace of innovation is increasing, and going “open” helps firms sustain this pace by shortening time to market and reducing R&D costs. These days, competition is won or lost on being able to over innovate your competitors, not trying to keep them in the dark. A good example of this approach was shown by Tesla in 2014 when it announced it was opening to anyone its portfolio of patents related to electric car technology. Explaining the move, Elon Musk wrote that Tesla would compete and win relying not on secrecy but on the talent of its engineers.

IP Concerns

Close to the fear of revealing proprietary information are concerns around Intellectual Property (IP) rights. Now, those are real concerns: confidentiality and IP still matter for many firms, especially tech companies. “What will happen if we include some sensitive data into our open innovation brief? We cannot control who will read it,” you can often hear.

These concerns, while real, are overblown. Techniques exist to write open innovation briefs in such a way that the identity of the firm that sponsors the initiative will be hidden. Moreover, very often, it is possible to write a problem statement without even revealing the technical application behind the problem.

Another concern is the so-called “IP contamination,” a fear that solutions coming from outside will “contaminate” IP generated within the firm. This is a real concern, too. But again, techniques exist (the “need-to-know” distribution of external information, using “IP-buffer” intermediaries, etc.) that can deal with this issue.

Yes, open innovation is not easy. But it can be learned, and the benefits of mastering this tool will justify the effort.

Check out my eBook, “We the People of the Crowd…,” a collection of stories about crowdsourcing reflecting my personal experience in working with corporate and nonprofit clients.

 Image credit: by Nick Fewings on Unsplash

About Eugene Ivanov

Eugene Ivanov is the Founder of (WoC)2, an innovation consultancy that helps organizations extract maximum value from the wisdom of crowds by coordinated use of internal and external crowdsourcing.
This entry was posted in Crowdsourcing, Innovation and tagged , , , , , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s