Not invented here syndrome is a phenomenon where people prefer to develop a solution internally, instead of adapting an existing external product. It is often motivated by a desire to maintain control, fears the unknown, and reduce expenses. In my career as a developer, scrum master, and now engineering manager I have had my fair share of not invented here syndrome. In this blog post, I will take you along in how I overcome the not invented here syndrome in my teams. By using a real story I experienced in the past.

The story

A few years ago we had a team that had to build a feature for our marketing department. A part of the feature was the ability for our marketing department to fill in content related to it. What we always did in the past was to build a microservice for this feature, add an interface to the backend, and create a small CMS there. It would take a couple of sprints in total. Building a WYSIWYG editor is always one of those things that is way more complex than it seems at first.

While this feature was being developed, one of our engineers went on a trip to another company. Get a look and feel how they tackle problems, how they organize, and any other learnings we can take away. The next day the engineer came back with his mind blown. Have you folks ever heard about Contentful? It is a headless CMS. Using it would make most of our content-related features a lot faster to build!

The team building the feature went back to the drawing board. Using the headless CMS instead of building one on our own made the feature much smaller. We removed several layers of complexity, and were able to deliver it faster!

But wait! Doesn't an external tool cost money? Don't you introduce a new dependency? Is this a new tool we need to learn? Let's take a look at those concerns below.

Mindset changes

The story might be a perfect example of Hanlon's razor, it was not that the team was unwilling to use a headless CMS, they did not know the thing existed!

If your team starts a new feature or big project, I've found that it helps to do timeboxed research in the orientation phase. Can we find any services that roughly do what we want in 30 minutes? If that is the case it requires a proper investigation.

Overcoming not invented here syndrome requires your engineering teams to change their mindset. Ours used to be to build everything ourselves. But in my years at an eCommerce company, I learned a surprising thing. In essence, most of you and your competitors share 80% of the features. Every webshop needs a place to write content or a contact form. Why should your engineering team spend their time and focus on creating/maintaining that 80%? While it will be much more interesting to focus on the 20% of the features that make you unique and drive the real value.

Focus on the peaks of your business (The 20%)

Some reason people use to justify not invented here syndrome is the costs. The development teams are there, and it does not cost me additional money. But an external service does cost me money. The solution to this problem is in the 80/20 rule. Sure the development team may not cost you any extra money. But the way I see it if the team can focus on that 20% unicorn magic that makes you special. It will earn you extra money in the long run. And then I'm not even taking into account that the features will be delivered sooner, and bring in value sooner!

Limiting dependency impact

A potential downside to overcoming not invented here syndrome is dependencies. Introducing an extra dependency can be tricky. What if we host all our content in one place, but that place has an outage?

The key to limiting the dependency impact is to think defensively. I'm a big fan of the term "defensive programming". Assume that everything can go wrong and act accordingly. In this example, it might be wise to add a layer of caching. If an endpoint returns something unexpected, try to make it a soft fail.

Nothing is worse than customers not being able to process a payment because the translation API on the thank you page is giving an unexpected response. Sure it might not look pretty to have untranslated words, but customers can still pay!

Acting defensively will help you in managing incidents. Instead of the entire site or page breaking, you might have some smaller features that do not work, but your core flow will be able to go through.

Before you leave

In this blog post, you learned about overcoming not invented here syndrome. Focus your time and attention on the 20% of your business that matters, and perhaps you can use some already existing tools to take care of the other 80% of your business.

To summarize not invented here syndrome for development teams:

• When implementing a new feature, check if there is a tool that already does what you want

• External tools might cost money, but that will free up your teams to work on the parts that bring the most value

• You need to be aware of the impact dependencies can have, program defensively, and limit the impact of external outages on your business.

If you liked this post, I think you might like these posts as well:

• How to create a culture where failing is acceptable

• No estimates

• Code reviews as a source of distrust

Subscribe to my newsletter to make sure you also get notified of any interesting new blog posts.