Dr. Wallace's Favorite Mental Models

Not Invented Here Syndrome

Why skilled teams rebuild perfectly good tools from scratch, and what the research actually says about when that instinct is costing you, and when it's the right call.

130-Second Overview

The fast version, if that's all you need right now.

What it is: Not Invented Here (NIH) syndrome is the tendency of a person, team, or organization to undervalue or reject outside ideas, research, tools, or solutions, preferring to build an in-house version instead, even when the outside option already works as well or better.
Where it comes from: The phrase describes a long-observed pattern in corporate and engineering culture. Its most cited empirical grounding is a 1982 study by Ralph Katz and Thomas J. Allen, published in R&D Management, which tracked 50 R&D project groups and found that performance tended to decline as teams aged together, especially past roughly five years, a pattern they linked to groups growing more insular and communicating less with outside sources of information.
The catch: Not every build-it-yourself decision is NIH bias. Security requirements, a genuine gap in available options, or a capability that is your actual competitive edge can all make building in-house the correct call. The syndrome specifically names the cases where an outside option is rejected for reasons of pride, turf, or unfamiliarity rather than an honest comparison.
Why it matters at work: It shows up in engineering teams maintaining a bespoke framework instead of a mature open-source one, in managers waving off a competitor's proven idea, and in departments ignoring a solution another team already built. The direct costs are duplicated effort and ongoing maintenance; the hidden cost is everything the team didn't ship while reinventing something that already existed.

2Mental Model Compass

Where Not Invented Here Syndrome sits next to three ideas people mix it up with constantly. Click a dot.

Mental Model Compass A scatter plot comparing four related mental models on two axes: whether the behavior resists or seeks outside input, and whether it is driven mainly by psychological self-protection or by a legitimate practical evaluation. Seeks outside input → ← Resists outside input Psychological / ego-driven ↑ Practical / cost-driven ↓ NIH Syndrome Proudly Found Elsewhere Status Quo Bias Build vs. Buy Analysis
Click any dot on the compass to see how that model relates to Not Invented Here Syndrome.

3Progressive Interactive Learning

Four short stages, each building on the last. Work through them in order the first time.

The phrase "not invented here" had circulated informally in engineering and corporate culture for decades before it was studied directly. The clearest empirical grounding came in 1982, when organizational researchers Ralph Katz and Thomas J. Allen published a study in R&D Management that tracked 50 project groups inside R&D organizations. They measured both how long each team had worked together and how much each team communicated with sources of information outside itself (other departments, outside experts, the broader technical community), and then compared both against each team's actual project performance.

Their core question wasn't "do teams get lazy over time": it was whether long-tenured teams change how they relate to outside information specifically. A team can stay hardworking and still become closed off, continuing to trust only what it has already built and discounting input that didn't originate inside the group.

Katz and Allen found that project performance tended to rise over a team's first year or two together, then decline, with the drop especially visible past roughly five years of stable team membership. They attributed the decline to a measurable fall in communication with outside sources of information: the team had grown insular, and with that insularity came a bias toward its own prior work and against ideas, tools, or solutions that came from elsewhere. That specific mechanism, not just general complacency, is what later writers started calling Not Invented Here syndrome.

One of the clearest organizational counter-examples is Procter & Gamble's "Connect & Develop" program, launched in the early 2000s under then-CEO A.G. Lafley. P&G set an explicit target of sourcing around half of its product innovations from outside its own R&D organization, the opposite instinct from NIH, sometimes called "proudly found elsewhere." Products including Olay Regenerist, Swiffer Dusters, Crest SpinBrush, and Mr. Clean Magic Eraser all developed from technology or ideas that originated outside P&G's own labs.

Several analysts point to a structural reason NIH persists beyond simple pride: engineers and researchers are often rewarded and promoted for building new things, not for successfully adopting or integrating someone else's. If recognition flows to "what I personally created" rather than "the best outcome for the project," the incentive to reject outside work is built into the system, not just a personality quirk of any one team.

In modern software teams, NIH shows up as a recognizable anti-pattern: a team dismisses a mature, widely used library or service with "we'll just build our own," then maintains that homegrown version indefinitely: patching it, documenting it poorly, and onboarding every new hire onto a tool nobody outside the company has ever seen. The direct cost is the engineering time spent rebuilding something that already existed; the larger cost is everything that time didn't go toward instead, plus an ongoing maintenance burden with no outside community to share it.

Not every in-house build is NIH bias. A team with a genuine security or compliance constraint, a capability that is the company's actual competitive edge, or a real gap in what the market offers has a legitimate reason to build. The honest test isn't "did we build it ourselves": it's whether the decision survived an honest look at the outside option's merits, or whether that comparison never really happened.

With AI coding assistants, mature open-source ecosystems, and inexpensive SaaS tools now covering most common engineering and business problems, the cost of reflexive NIH behavior has gone up, not down: the gap between "what a team built from scratch" and "what was already available, cheaply, elsewhere" is now often larger and easier to measure. At the same time, a newer, opposite failure has become common: uncritically adopting every new external tool or AI feature without the same honest evaluation NIH skeptics are asking for, a pattern closer to Shiny Object Syndrome than to healthy openness.

An AI assistant that always defaults to writing custom code, even when a well-maintained library already solves the problem, can quietly encode NIH bias into a team's workflow at scale. The useful question to ask any build decision, human or AI-suggested, is the same one Katz and Allen's data points toward: has this actually been compared against the outside option, or did the comparison just not happen?
Stage 1 of 4

4Diverse Examples

The same mechanism, four different settings.

A platform team dismisses a widely used, well-maintained job-scheduling library with "we'll just build our own," confident it will be simple. Years later the in-house scheduler is still missing features the mature library had from day one, has no outside community to help when something breaks, and every new engineer needs a special onboarding session just to understand it. The company is now paying, indefinitely, for a weaker version of something it could have adopted in an afternoon.

Procter & Gamble's "Connect & Develop" program, launched under CEO A.G. Lafley in the early 2000s, explicitly set out to source around half of the company's product innovations from outside its own labs, a deliberate counter-program to NIH instinct. Olay Regenerist, Swiffer Dusters, Crest SpinBrush, and Mr. Clean Magic Eraser all trace back to technology or ideas P&G found elsewhere and brought in, rather than insisting on developing from scratch.

Katz and Allen's 1982 study found that R&D project teams, after enough time working together (especially beyond roughly five years), communicated less with outside sources of technical information and saw their performance decline. A team of excellent individual researchers became, collectively, a less effective one: not from losing skill, but from quietly cutting itself off from outside input.

Someone renovating a room insists on figuring out the wiring themselves from scratch, despite a neighbor who did the identical job last year and offered to walk them through exactly what worked. Pride in "doing it myself" costs several extra weekends and at least one mistake the neighbor's experience would have prevented: a small, personal version of the same pattern that shows up in R&D labs and engineering teams.

5Worked Application

A six-step way to run an honest build-vs-adopt decision, instead of either defaulting to "build it ourselves" or labeling every in-house project as NIH bias.

  1. Name the specific decision. Be concrete: one tool, library, process, or idea under consideration, not a general philosophy about building versus buying.
  2. List the honest merits of the outside option, on its own terms. Maturity, cost, existing community support, and track record all count, even if the option feels unfamiliar or was built by people outside your team.
  3. List the legitimate reasons building in-house might still be right. A real security or compliance requirement, a genuine gap in what's available, or a capability that is your actual competitive advantage are all legitimate; write down which, specifically, applies here.
  4. Separate those from ego or turf reasons in disguise. "We know better," a past bad experience with some unrelated outside tool, or simple unfamiliarity are not the same as a legitimate reason, even when they're dressed up as one.
  5. Check who benefits from the choice versus who carries the maintenance cost. If the people deciding to build get credit for the new project while a different team inherits years of upkeep, that incentive mismatch is often doing more work than any technical argument.
  6. Write the decision down, with the reasoning, and set a date to revisit it. Circumstances change (a library matures, a vendor improves, a team's own priorities shift), and a decision worth making once is worth re-checking later rather than defending forever.

6Common Mistakes

Calling every in-house build "NIH bias"

Sometimes building it yourself is genuinely the right call: a real security constraint, a true capability gap, or a core competitive advantage. The label only fits when the outside option was rejected without an honest comparison.

Confusing it with legitimate security or compliance caution

Declining to adopt unreviewed third-party code for a real risk reason is sound engineering judgment, not NIH syndrome. The syndrome is specifically about rejecting good outside options for reasons of pride or unfamiliarity.

Underestimating the ongoing maintenance cost

The upfront build is rarely the real cost. Every homegrown system needs patches, documentation, and onboarding indefinitely, usually without an outside community to share that burden, a cost that compounds for years after the original decision.

Overcorrecting into reflexive adoption of everything external

The fix for NIH isn't "always prefer outside tools": uncritically adopting every new library, vendor, or AI feature without the same honest evaluation is its own failure mode, closer to Shiny Object Syndrome than to healthy openness.

7When Not To Use It

Don't use it to dismiss a well-reasoned build decision

If a team has honestly weighed the outside option and still chose to build for a real reason (security, a true capability gap, a core differentiator), calling that "NIH" is just a label replacing an actual argument.

Don't apply it where genuine security, legal, or IP constraints exist

Some outside code, data, or ideas genuinely cannot be adopted for compliance or intellectual-property reasons. That's risk management, not insularity.

Don't use it to argue for permanent, uncritical reliance on vendors

The healthy state is a deliberate, periodically revisited choice between building and adopting, not a reflex toward either side. Treating "always buy" as the lesson overcorrects just as much as reflexive building does.

9Try It Yourself

Fill in a real build-vs-adopt decision you're facing or reconsidering. This builds a short, specific prompt you can paste into any AI assistant or use to interview your own team.


    

      
      Copied
    

  






  
10Save as Skill

  
A portable, reusable version of this model you can hand to an AI assistant or your future self.

  

    
Preview

    

    

      
      
      Copied
    


    
Apply to My Problem

    
Describe a live build-vs-adopt situation and generate a ready-to-paste prompt that applies this model to it.

    
    
    

    

      
      Copied