What is Not invented here syndrome?
Engineering culture
Not invented here syndrome is the habit of distrusting or rejecting ideas, tools, or code mainly because they came from outside the team or organisation. In software, it shows up when engineers rebuild things that already exist, resist shared standards, or assume in-house work is automatically better. Sometimes that instinct hides pride or tribalism. Sometimes it reflects real concerns about control, licensing, security, or maintenance. The hard part is telling those apart.
What this means
Every engineering team has to decide what to create itself and what to adopt from elsewhere. That might mean buying a product, using an open source library, sharing an internal platform, or accepting a standard built by another team. Not invented here syndrome appears when that choice has already been emotionally made before the evidence is examined.
The phrase is usually used as criticism, but it is not quite as simple as "building your own is bad". Teams do sometimes have good reasons to avoid external dependencies. They may need deeper control, better security review, tighter performance, or a stronger product distinction. The syndrome is the bias, not the mere act of building.
Why it matters
This bit of engineering culture matters because it sits right in the middle of cost, speed, and ownership. A team with strong NIH instincts can spend months rebuilding plumbing that adds little advantage. A team with no scepticism at all can import brittle dependencies, create vendor lock-in, or hand strategic capability to somebody else. The choice is rarely technical only. It is cultural, political, and economic at the same time.
It also matters for anyone working alongside engineers. Product leaders and executives often hear, "we should build this ourselves", and assume it is a clean technical conclusion. Sometimes it is. Sometimes it is an identity statement in disguise. Knowing the term helps you ask better questions before a preference becomes a multi quarter commitment.
How it works
Where the term came from
The phrase came out of research and management discussion around research and development groups that became inward looking over time. In technology, it stuck because the pattern is easy to recognise. A team treats outside work as suspicious by default and inside work as trustworthy by default, even when the evidence points the other way.
That default can be subtle. Nobody announces, "we reject outside ideas". Instead people say, "we need something more tailored", "that library is not production grade", or "we can knock up a better version in a sprint". Sometimes those judgements are right. NIH is what happens when they become habitual and self flattering.
Why engineers are prone to it
Part of the answer is control. Other people's code comes with unfamiliar assumptions, release schedules, bug priorities, naming choices, and support models. Reading it is slower than writing fresh code. Adapting it can feel like compromise. That discomfort is real, and it often nudges teams toward rebuilding.
Part of it is pride. Software is a craft, and engineers quite reasonably care about quality. If a team has been burned by a poor vendor or a messy shared platform, "we should own this ourselves" can feel like competence rather than ego. The trouble is that competence and possessiveness can sound identical in early meetings.
There is also a local incentive problem. Building new things is visible and prestigious. Integrating somebody else's work, improving upstream documentation, or hardening a shared internal library is less glamorous. Many organisations celebrate invention more than careful adoption. Given those incentives, NIH can look like initiative.
When the instinct is sensible
This is where the term needs care. Rejecting an external component is not automatically irrational. It may be wise if the capability is central to your product, if legal or security constraints are severe, if the upstream project is abandoned, or if the dependency would create a long chain of support headaches. Joel Spolsky made the useful counterpoint years ago that reuse can create nasty interdependencies. Shared code is not free just because you did not type it.
A healthy team therefore asks two different questions. First, is the external thing good enough for our actual need? Second, what does owning the thing ourselves really cost over time? NIH syndrome sets in when the first question is dismissed and the second is fantasised away.
The best counterculture may be the phrase "proudly found elsewhere". It captures a mature engineering attitude. Use what already works when it truly fits. Build where ownership is strategically worth the long term burden. Do not confuse novelty with advantage.
Examples
A company already has a shared authentication platform used by several products. A new team decides to write its own because the shared platform team is "too slow". Eighteen months later they are maintaining login flows, password resets, audit trails, and compliance work that were never part of their product's distinctive value.
A backend team refuses to use a mature open source queue library because they are sure they can produce a slimmer internal version. They can, at first. Then message ordering, retries, observability, upgrades, and documentation arrive like uninvited relatives. The queue becomes a side business.
An organisation creates four slightly different internal design systems because every product group wants autonomy. Each system is reasonable on its own. Together they create duplicated accessibility work, duplicated component bugs, and duplicated onboarding pain.
Common misunderstandings
Not invented here syndrome does not mean every in-house build is vanity. Sometimes building is exactly right, especially for a capability that defines the product or carries unusual constraints.
It is also not cured by shouting "build versus buy" and declaring the cheaper number the winner. Adoption has integration costs, governance costs, and escape costs. Building has maintenance costs, staffing costs, and edge case costs. The comparison needs both sides.
Another misunderstanding is that NIH is just a management problem. It can live anywhere. Individual engineers do it, teams do it, and executives do it. The executive version is often buying a shiny external platform because internal work feels old and unexciting.
Finally, the opposite extreme is not wisdom. Blindly importing every dependency, service, or acquired tool because somebody else already made it is a different kind of poor judgement, and it often ends in dependency hell.
Risks and boundaries
The phrase can become a conversation stopper. If every careful objection to an external dependency is labelled NIH, teams lose the ability to discuss real issues such as data residency, security review, operability, skill fit, or total cost of ownership. Calling somebody NIH should never save you the work of making the case.
There is also a human boundary. Sometimes what looks like NIH is fear. Teams know their own stack, their own pager load, and their own deadlines. They may resist outside code because they do not trust that the organisation will support them when integration gets difficult. In that case the real issue is not arrogance. It is the absence of shared trust.
What to do next
Start by making build, adopt, fork, and buy explicit options rather than tribal identities. Ask each team to write down why a capability is worth owning, what burden comes with that ownership, and what would have to be true for an external alternative to be acceptable.
Reward integration and stewardship work. If promotions and praise only follow greenfield building, people will keep rebuilding. Teams should get credit for reducing duplication, contributing fixes upstream, improving shared platforms, and retiring unnecessary local copies.
It also helps to define what is genuinely strategic. A company does not need bespoke everything. It needs clear reasons for the few things it truly wants to control deeply. Once that line is visible, many NIH debates become less emotional and more honest.
FAQs
Is Not invented here syndrome the same as build versus buy?
No. Build versus buy is the decision. NIH is the bias that can distort that decision before evidence is weighed properly.
Can open source reduce NIH?
Often, yes. Open source can make external code easier to inspect, test, and improve. But it does not remove maintenance, upgrades, or governance concerns.
What is the opposite of NIH?
People sometimes say "proudly found elsewhere". The unhealthy opposite is importing things uncritically just because they are fashionable or external.
Is NIH always irrational?
No. External tools and code really do bring dependency, support, and lock-in costs. The problem is rejecting them by reflex rather than by careful judgement.
How can a team tell whether it is being fair?
Ask for a written comparison of adoption cost, ownership cost, risk, and strategic relevance. If the argument depends mainly on taste or pride, NIH may be at work.
Does NIH only happen with outside vendors?
No. It often happens inside large companies when one product team rejects internal platforms or ignores code built by another group.
Sources
Documentation/CodingStyle and Beyond (Ottawa Linux Symposium). A grounded engineering example that explicitly tells kernel contributors to reuse well designed, well debugged facilities rather than reinventing them.