“Not-Invented-Here” syndrome in pharma
Do you jeopardize the safety of your #biotech or #pharma company because of “Not Invented Here” (N-I-H) syndrome? Here is what you need to be aware of!
I have just recently learned the term “Not Invented Here Syndrome” from an episode of “The Readout Loud” — a podcast about biotech from Stat. In that episode, dedicated to AI in biotech, Joel Dudley discussed how pharma companies are resistant to bringing in external innovation, and N-I-H was to blame (not to mix-up with the National Institute of Health — just this once it’s not their fault!)
Not-Invented-Here Syndrome
N-I-H syndrome is when companies refuse to bring in external technology because they believe they could invent it internally. Another manifestation is when you rather spend money on FTE than on external solution, even when external solution produces the result faster and cheaper. This phenomenon seems to be especially prevalent when it comes to data science and software solutions, but is really widespread across all aspects of life (makes me think of my parents who deeply opposed buying a dishwasher because they believed they could wash dishes much better).
N-I-H in pharma
It is not uncommon for pharma companies to have an internal set of apps and tools to address their data needs. Pharma hires armies of data scientists and bioinformaticians, in a hope to extract valuable insights from “the new oil” generated from their experiments, trials and collaborations. Many of these people are highly skilled, with PhDs, proven scientific credentials and long list of publications. Given the task, these people can create incredible solutions, outperform 90% of their peers, and most certainly implement almost any solution out there, given enough time and resources. Then why does pharma end up with fragmented space of apps, databases and reports addressing isolated research questions, often with suboptimal user experience?
I have seen plethora of apps and platforms developed within a company, typically done by a single person, most of the time not maintained as soon as the original author leaves the company/ research institute. “Why does this happen?” you might ask.
N-I-H as an execution risk
In venture there are 3 key risks that a startup is facing: market risk, technology risk and execution risk, and N-I-H behavior can seriously aggravate your execution risk as a team.
- N-I-H opposes growth mindset
N-I-H is particularly common among junior professionals who still need to prove themselves in a workplace, and see the external solution as the professional threat undermining their abilities. As the person starts moving into more senior positions, where they need to think about the success of the project more than individual success, they become more likely to look for external solutions to optimize their time. They spend much more time thinking about how to make things more efficient than about how to become a valuable employee.
- N-I-H creates security risks
The race to “invent here” has led to some pretty grave security risks that I have witnessed in my career. From newcomers using computational servers of a previous job to run bioinformatics analytics (usually because the new company hasn’t setup computational resources and it takes time setup), to Gitlab/Github repositories that are open access or unmanaged, so former employees have access to it years after leaving the company. The key issue here is that academic and in-house software doesn’t require to pass certifications and be regulation compliant to a degree which is required for enterprise solutions — the fact that I learned a hard way when starting my own company and realizing how much stricter the requirements are for user and data protection.
I would be a hypocrite if I didn’t admit that I was guilty of N-I-H syndrome myself at times, often due to a poor understanding of how companies and organizations prioritize spending. But the pressure of building a startup leaves no space for pride — there are many things I could build myself, but is this what gets me to the result the fastest?
A consideration of whether to develop something in-house, or get an external solution has to be strategic, and often cannot be answered just by asking your bioinformaticians whether they can do it themselves (of course they can). Better ask this:
— How long would it take you to build such solution yourself if you had no other projects?
— What other projects will be delayed and set aside for you to execute this?
— How much time would you need to spend in the future to maintain the solution?
— How will you ensure that this solution is maintainable and accessible in case you leave the company?
And remember: building software takes a team of people with very variable expertise, management of the computational servers or a cloud, bioinformatics methods, backend architecture, front-end, UX/UI designers to just name a few. So if software is not your primary business model, external solutions might just be your best bet.
