i

Description

La roue d'une vieille remorque à plateau de bois, dans un entrepôt.

Source

W.carter · original page

Licence

CC0 Public domain

Original photo, unretouched. The background is a version of it stylised by the site.

The “Not Invented Here” syndrome

An idea, a component or a method is set aside not for its flaws, but because it does not come from us.

In brief

• What: we dismiss, or rebuild in-house, what was designed elsewhere, without having evaluated it on its merits.
• Why: professional pride, group identity, perceived loss of control, fondness for what we built.
• Detect: “we'd do it better ourselves,” different evaluation criteria for outside and inside.
• Avoid: compare build, buy and reuse on the same criteria, cost the full picture, keep a decision log.

On this page

1. Definition
2. The mechanism
3. Where we encounter it
   1. In project management
   2. In management
4. Famous cases
   1. A group's tenure and its isolation 1982
   2. Procter & Gamble: from “not invented here” to “proudly found elsewhere” 2000-2006
   3. The left-pad counter-example March 22, 2016
5. Warning signs
6. Avoidance reflexes
7. With AI: detect, remedy, mitigate
   1. Detect
   2. Fix
   3. Mitigate
   4. Prompts to build into your practice
   5. How to build them in
   6. Precautions
8. Limits
9. Sources and verification
10. See also
    1. Combines with, or reinforces
    2. Related biases
    3. Counterweights and related reflexes

Definition#

Fictitious illustration

The “not invented here” syndrome (NIH) is the tendency of a group to reject an idea, a product or a practice because it comes from outside, even when it would fit. The typical result: we rebuild in-house what already existed, at greater cost and often with lower quality.

The expression is old in research and development management. It was studied by Ralph Katz and Thomas Allen (1982), who examined 50 R&D project groups in three organizations: teams with a long average tenure communicated less with the outside of their organization and performed worse.

It is not a “pure” cognitive bias: it combines several mechanisms (see below) and an organizational factor, the group's culture. That is why it is classed among collective decision biases.

The mechanism#

• Identity and pride. For a team of engineers, adopting someone else's solution may feel like admitting they could not have built it. Skills and autonomy are part of the group's identity.
• The “home” effect. We know the flaws of what we wrote and forgive them; we only see the flaws of what we did not write (see the IKEA effect and in-group bias).
• Perceived control. Depending on an outside component is experienced as a loss of control (lead times, evolution, support). The risk is real, but it is generally overestimated compared with the more diffuse risk of what we maintain ourselves.
• Invisible costs. The purchase cost is displayed; the cost of building, maintenance and opportunity is not. The comparison is skewed before it has even begun.
• Gradual isolation. The more stable and closed a group is, the fewer new ideas it receives, and the more suspect it finds them: this is the dynamic identified by Katz and Allen.

Where we encounter it#

In project management#

• Component choices: “we'll write our own workflow engine / data access library / scheduler” when mature ones exist.
• Open source and vendors: the existing library is dismissed over a minor defect, or a style detail, while we tolerate far worse in in-house code.
• Another team's tools: the neighboring department offers its testing framework or authentication module, and each team ends up maintaining its own.
• Reusing what exists: a component inherited from another project is redone “because we don't understand how it works,” without having read it.
• External standards and practices: we reinvent an exchange format, a naming convention or a process when a standard exists.

In management#

• Methods from elsewhere: a practice from another company, another department or a book is rejected out of hand (“that wouldn't work here”), without a trial.
• Hiring and consulting: a consultant's or a new hire's opinion is listened to less than a long-time colleague's, with equal content.
• Relations between departments: one department refuses another's deliverables “because that's not how we do things,” and each builds its own tracking tool.
• Team dynamics: teams that have worked together for a long time close themselves off to new ideas without realizing it.

Famous cases#

Warning signs#

• “We'd do this better ourselves” said before any evaluation.
• The criteria applied to the outside product (maturity, support, security) are not applied to in-house code.
• Several teams in the same company maintain equivalent tools.
• The in-house development cost is compared with the purchase price without several years of maintenance.
• The arguments against the outside solution are vague (“not suited to our context,” “we'd lose control”).
• Ideas from newcomers or neighboring teams are received with condescension.

Avoidance reflexes#

1. Apply the same criteria to both sides. Write the grid before the review (features, quality, security, license, cost, scalability) and score the internal solution and the outside solutions with the same grid.
2. Cost the full picture. Development, testing, documentation, maintenance, upskilling, on-call: over three to five years, for building as well as for buying or reusing.
3. Ask what sets us apart. Build what gives the product its own value; buy or reuse what is commonplace (authentication, logging, formats, scheduling).
4. Test before rejecting. A short, bounded proof of concept is better than a judgment on paper.
5. Open up the group. Cross-reviews with other teams, rotations, external presentations, regular watch: groups that exchange resist NIH better.
6. Record the decision. Note the options, the criteria and the reason for the choice (an architecture decision record is enough) so it can be revisited.
7. Reward reuse. Publicly recognize those who adopt someone else's good solution rather than those who rewrite.

With AI: detect, remedy, mitigate#

Prompts to build into your practice#

1. Build, buy or reuse grid. Before deciding to develop a component in-house.

We are considering developing [component / function] in-house. Help me compare three options objectively: build, reuse an existing solution (open source or commercial), or adapt an existing internal component.
1. Propose a grid of 8 to 10 criteria (features, quality, security, license, acquisition cost, 5-year maintenance cost, scalability, support, dependency risk, skills required).
2. For each option, say what we would need to know to score it, without inventing data: flag what you do not know.
3. Name families of existing solutions to examine, specifying that their existence and current state will have to be checked.

Context: [need, constraints, skills, expected lifespan]

2. Advocate for the outside solution. When the team dismisses a solution before evaluating it.

Here are the reasons why we are rejecting [outside solution]: [list].
Play the advocate for this solution. For each reason, say whether it rests on a verifiable fact or on an impression, what check would test it, and whether the same objection would apply to our internal solution.
Finish with the three cheapest trials that would settle the question.

How to build them in#

• At pre-project stage: prompt 1 produces a grid that the team corrects and validates before choosing.
• In an architecture committee: prompt 2 serves as devil's advocate on any decision to build.
• In a retrospective: review the build decisions of a year ago, with their actual cost.

Precautions#

• Check that the products, libraries and versions cited exist: an AI can invent them or cite abandoned projects.
• Do not paste proprietary code, contracts or customer data into an unauthorized tool.
• A grid produced by AI reflects common vocabulary; criteria specific to your context (regulation, hosting, sovereignty) have to be added by you.

Limits#

• NIH is an organizational syndrome more than a measurable individual bias; the studies are mostly field surveys, whose results depend on context.
• Rejecting an outside solution is not always NIH: security, license, sovereignty, migration cost or competitive advantage can be good reasons. The bias begins when the reason is provenance.
• The opposite excess exists: depending on everything also means losing control (see the left-pad case), and a systematic taste for the outside falls under pro-innovation bias or the fashion effect.
• The Procter & Gamble figures come from the company's own communications.

Sources and verification#

• Katz & Allen (1982), “Investigating the Not Invented Here (NIH) syndrome: A look at the performance, tenure, and communication patterns of 50 R&D Project Groups,” R&D Management, 12(1)
• Huston & Sakkab (2006), “Connect and Develop: Inside Procter & Gamble's New Model for Innovation,” Harvard Business Review, March 2006
• Quartz (2016), “How one programmer broke the internet by deleting a tiny piece of code” — the left-pad affair.
• Lafley, A. G. & Charan, R. (2008), The Game-Changer, Crown Business — Procter & Gamble's open innovation approach.

See also#