How Not invented here kills innovation and 5 rules to avoid it

In an age of fast technological development in a connected world, trying to reinvent and build everything yourself is a ridiculous notion. Still, many companies do just that instead of leveraging the ingenuity of a lively developer community. They are wasting time and resources on problems that have already been solved instead of building successful products for their customers.

Many times during my career, I was faced with the decision of whether we should “make or buy”. This often led to a dichotomy; management usually tends to lean towards “buy” while tech teams prefer “make”. This is no surprise as management wants a minimum time to market and tangible results, whereas the tech teams connect their very raison d’être to the ability to deliver (and maintain) software.

Under professional circumstances, this can spark a fact-based discussion about the best strategy, especially because every use case is different. There is nothing bad about “do it yourself”, unless the decision is influenced by the “not invented here” problem—which of course not every management is immune to, either.

The “not invented here” (NIH) problem is a cognitive bias that leads individuals and organizations to reject or undervalue external ideas and innovations in favor of internally developed solutions.

Sometimes, it’s even quite a prominent mindset in companies or teams that have been surfing a wave of success for a long time, or who have been led by overly self-confident leaders. This fosters a feeling of infallibility—of superiority—which leads to disdain for solutions provided by external people and organizations. After all, how can someone else do something better, faster or cooler than our team? And even if that were the case, we’d still do it ourselves and in our specific rockstar way, because we can.

In other words, whole organizations as well as individuals on teams can be too proud of their own work than they could accept someone else’s work as superior, or their ideas worth investigating.

The size of a company or team doesn’t make a difference; nobody is immune to this. When I was talking to an integration team of a major blue-chip software solutions company from Germany a few years ago, the team was oozing self-confidence even though their solution was clearly falling short in comparison to other players in the market. However, their pride and prejudice left no room for doubt—after all, their company had been a software heavyweight for decades (though largely based on legacy business in recent years).

On an individual level, I was talking about WunderGraph with a solution architect from a large furniture company who told me that they were building all the WunderGraph functionality themselves. When I asked (nicely) whether their resources wouldn’t be better spent on selling furniture and building a great user experience rather than recreating something complicated that already exists, he was offended. He told me very directly that he knew this best; that he had the best team; and that there wasn’t a solution that could do what his solution would be able to do.

It’s hard to argue against “not invented here”, because it is also, on many occasions, a personal thing. Rational arguments, just like with the solution architect I met, don’t count in such cases.

Let’s look at the psychological factors that contribute to NIH:

• Confirmation bias : this is the tendency to favor information that confirms one's pre-existing beliefs, leading to the dismissal of external ideas. It gets even worse if the external ideas sound counterintuitive.
• Groupthink : a phenomenon that occurs when a group prioritizes consensus over critical thinking, resulting in the belief that only internally developed ideas are valuable. Opinionated leaders play a critical role as their approach of external ideas will set the scene for the entire team: if they support open-mindedness, so will the team. If they think there’s no match out there, so will the team.
• Loss of control: the fear of introducing a solution or software that represents a black box, or that adds dependencies to external suppliers, with the effect that someone is no longer able to autonomously resolve problems or take ownership
• Pride and ownership: the attachment to one's own ideas can create resistance to adopting external solutions. In my experience, this is the most critical and also the most common aspect as this makes it a personal thing. If someone else does something better than me, I might feel inferior, less important, or less competent. It gets worse if some new hotshot person successfully lobbies for an idea that makes me and my work look outdated, or my plans not properly thought through. And if I feel like this could threaten my position or job, it quickly becomes an irrational knives-out situation.

As always, various fears and our human aversion to change are the driving forces. If I think I’m on the right path, any deviation from it will lead to uncertainty and change—and our brain will go to great lengths to avoid this.

Anatomically, this is our reptile brain / the amygdala speaking. Time to give the cerebrum some airtime for reason and rationality!

It’s pretty obvious, but since NIH is so common, I need to call it out once more: if you want to deliberately redo (“reinventing” is actually an oxymoron) something that already exists, you:

• waste time: other projects have to wait in the meantime—projects your customers and users are likely waiting for
• waste money twice: time is money, and resources that don’t create value are a money pit. What’s worse, the features you can’t build because of this will arrive later and thus fail to add to the company’s revenue sooner
• miss growth opportunities: time to market can give you the upper hand on the competition. If you delivery later than you could have, someone else might collect all the laurels (and customers) for a feature that you already had in the pipeline
• stifle innovation: resources spent on redoing things can’t work on creating original ideas
• give a bad example: rather than fostering an open mindset and the ability to move quickly, you encourage people to disregard existing solutions and build a bias towards everything that’s “home-made”
• put your company at risk: if you don’t innovate, you may simply be left behind by your competitors

A good example of the positive effects of building on top of the results of others is the API economy or the way the scientific community works. Nobody would consider not using past research to make new discoveries; otherwise, we would likely still be living in medieval times when new ideas traveled slowly and things were “invented” over and over again.

Revisiting the title of this article, I’d like to stress again what NIH does to innovation: it keeps us as an industry from building better solutions faster. Countless developer hours are wasted each week because organizations don’t leverage existing concepts and software. In a hyperconnected world, can we afford to spend time on anything that already exists?

Of course, giving some concept an overhaul with a new angle or twist can also be innovative, but if it’s just the same thing in a different color, it doesn’t count as innovation.

Also, this article is not a plea against building things in-house. This, by all means, is a legitimate decision. The point is that it should be taken on a rational appraisal of the facts.

Before you decide to build something in-house rather than going for an existing solution, ask yourself:

1. Can we really add fundamental new value that can’t be added otherwise, e.g., by extending an existing solution?
2. Can we build it faster or cheaper than adopting an existing solution (with necessary changes)?
3. Is this the only way we can ensure the level of security we need?
4. Do we need to build this ourselves to avoid copyright or monetization issues?
5. Can we handle the technical liabilities (e.g., maintenance) if we build it ourselves?

If the answer to all questions is “yes”, it’s a no-brainer, of course. And it’s the same case for the security and copyright questions: “yes” basically equals a carte blanche. However, if these two things are not an issue, you absolutely should be able to give a clear ”yes” as an answer to the first two questions.

Open-source software is per definition a work of many and truly collaborative in nature—maybe the antithesis of NIH. By collaborating on open source projects, developers automatically gain a deep understanding of how fast you can iterate if you keep a project open to input from a large group of people (exceptions confirm the rule ;).

What’s more, open-source software is not a black box, which counters the fear of loss of control. Also, you will never have the problem that a single person or organization will claim ownership of open-source code; and thus, be affected by their pride if someone else comes knocking with a better idea. On the contrary, new concepts usually get assimilated quite quickly into open-source projects, provided they are not run by just very few individuals.

Of course, it’s not all happy and shiny in the open-source world, either. But I believe you will have a hard time finding the NIH problem here (if you have a different opinion, please leave a comment here or on Twitter ).

So, what is it you can do to avoid NIH?

1. Be smart by accepting you’re not the smartest (in every area). There are many people out there who have solved your problem already: find what you can build upon and create specific value on top of that.
2. Don’t make it your baby. As soon as this happens, you are likely to have your feelings hurt if you find out your solution is not (or no longer) the hottest sh.t in town. Maintain a professional distance to what you build and always expect the day that you will have to replace it.
3. Work in a startup (or a startup environment). It will quickly teach you that you can’t waste time on things that don’t move the needle, or else you will quickly run out of runway. Pick your battles wisely and find the spot where you can deliver the best original value.
4. Foster an organization that embraces change and frequently reflects on what is being built, how it is built, and how others do it. Ideally, use alternative solutions just to try them out and learn as much as you can, and have different team members advocate for them.
5. Encourage developers to work on open-source projects. This broadens their perspective, increases understanding of cross functional and cross cultural collaboration, and lowers the threshold to accept working with external code.

If you still decide to build things yourself under these circumstances, you can be pretty sure that it is a sound decision. :)