ABOUT 2 HOURS AGO • 10 MIN READ • COGNITION CATALOG

🤝 The trick to getting a team to adopt an outside idea

profile

Join 10,000+ designers improving their soft skills, weekly!

Beyond UX Design's mission is to give you the tools you need to be a truly effective UX designer by diving into the soft skills they won't be teaching you in school or a boot camp. These skills are critical to your success.

Not Invented Here

We tend to reject or undervalue ideas, tools, and research that come from outside our own team, and overvalue the ones we built ourselves. The origin of an idea ends up carrying more weight than its quality.

But first, let's hear from this week's sponsor...

Now, back to Not Invtented Here ⏬

When your team says an outside idea "won't work for us," are you evaluating the idea, or just the team it came from?

A few years back at GE, a mandate came down from the top.

A central design system team out in CA had built one design system for every software group in the company. It was well documented, thoughtfully built, and clearly a ton of work had gone into it.

The message was simple: this is the system now. Everybody uses it.

And almost every team said the same thing:

➡️ "It doesn't cover our use case."
➡️ "Our users are different."
➡️ "We've already got something that works."

Basically: we're special, we're a little snowflake, the rules don't apply to us.

Here's what I kept noticing, though. Nobody ever said, "We tried it, but it didn’t work." They said "that won't work for us" before they'd really tried it.

The system got judged on where it came from, not on what it could actually do.

That's Not Invented Here. The tendency to reject or undervalue ideas, tools, and research from outside your own team. And "outside" doesn’t have to be another company. It can be another team, another function, or just a different job title.

It's why an engineer's UX suggestion gets waved off because UX is "our lane." It's why agency research suddenly has questionable methodology the second it disagrees with you. It's why ten teams rebuild the same component ten different ways, and then nobody trusts the design system anymore.

This week on the Cognition Catalog, I get into where this bias comes from, how it quietly makes good teams worse over time, and a few practical ways to catch it before it costs you a quarter.

video preview​

Would you rather listen? Follow the Cognition Catalog on Spotify!

show
Not Invented Here: When “We’...
Sep 17 ¡ Beyond UX Design
16:53
Spotify Logo
 
​

Most cognitive biases have a psychology lab origin story. This one comes from engineering management.

In 1982, Ralph Katz and Thomas Allen at MIT’s Sloan School studied 50 R&D project groups inside a large lab. They were looking at how team tenure affected performance. What they found was a curve. Groups got better for about a year and a half, held steady for a while, and then started sliding. By the five-year mark, performance had dropped noticeably.

The reason wasn’t burnout or boredom. It was communication. The longer a group stayed together, the less its members talked to people outside the group, including the outside sources they most needed to hear from. Katz and Allen described the pattern as a stable team coming to believe it held a monopoly on knowledge in its field, and rejecting outside ideas as a result. They called it the Not Invented Here syndrome, borrowing a phrase engineers had already been using as an insult for years.

That’s the founding study. Since then, the research has mostly lived in innovation and knowledge management journals rather than psychology.

The most useful modern framing comes from David Antons and Frank Piller at RWTH Aachen University. In 2015, they argued that Not Invented Here isn’t really a behavior. It’s an attitude, a standing negative feeling toward knowledge that gets labeled “external.” And “external” turns out to be flexible. Knowledge can feel foreign because it came from a different discipline, a different department, or a different location. Any of those boundaries can trigger the reaction.

That’s the part worth sitting with. The bias isn’t about ideas being bad. It’s about ideas being theirs.

Why does the brain do this? A few overlapping reasons, and I’ll flag that this next bit is synthesis rather than a single study.

First, ownership feels like competence. If our team built the thing, we understand it, we can defend it, and we get credit for it. An outside solution offers none of that, even when it works better.

Second, evaluating outside work is expensive. Learning someone else’s approach means admitting you don’t already know it, and building your own means starting from what you do know. The second path feels faster even when it’s slower.

Third, group identity. Teams bond over shared work, and outside ideas can feel like a quiet challenge to the group’s sense of itself. Rejecting them protects the tribe.

A 2019 study led by Julian Hannen, again with Antons and Piller, put a number on the cost. Across the R&D professionals they surveyed, every one-point increase in Not Invented Here attitude corresponded to roughly a six percent decrease in how much external knowledge actually got absorbed. Small attitude shifts, measurable losses.

One more thing. The bias has a defense. In 2001, software developer Joel Spolsky wrote a widely shared essay arguing that strong teams should build their core stuff themselves, because nobody else’s work meets their bar. He wasn’t entirely wrong. Sometimes building it in-house is the right call.

The problem is when the source decides the answer before the evaluation happens.

SPONSOR

Save hours of UI and UX research with our library of 600,000+ fully searchable mobile and web app screenshots. Use my link, mobbin.com/beyondux, to get 20% off Mobbin Pro!

​

Nobody in a meeting says, "I reject this because we didn't make it." What people tend to say is "that doesn't fit our context," or "we already tried something like that," or "our users are different." And sure, sometimes those statements are true. The bias is what happens when that is the first reaction rather than any real finding.

On product teams, the clearest version shows up between disciplines. An engineer suggests a UX change and design dismisses it before looking closely, because usability isn't their lane. A designer proposes a technical approach and engineering does the same. The boundary that makes the idea feel external isn't a company wall. It's a job title.

Research gets hit hard by this. A team commissions a study from an outside agency, and when the findings contradict the team's assumptions, the methodology suddenly looks questionable. Meanwhile, a hallway conversation with one internal stakeholder gets treated as solid evidence. The difference isn't rigor. The agency's work came from outside.

Design systems are a running battleground. A platform team ships a component. A product squad rebuilds nearly the same thing because the shared version "doesn't quite work for us." Multiply that across ten squads, and you have ten date pickers, ten sets of bugs, and a design system nobody trusts.

Engineering has its own famous version: rewriting a library instead of adopting one. Sometimes the rewrite is justified. Often it's a year of effort to reproduce something that already existed, with fewer tests.

Product managers do it with competitor patterns. A rival ships a flow that clearly works, and the PM's instinct is to differentiate rather than learn. Users don't reward originality for its own sake. They reward things that work.

Then there's the acquired team. A company buys a startup, and within months the startup's codebase, research, and product instincts are being replaced by the parent company's versions. The purchase price bought the knowledge. Not Invented Here throws it away.

The cost isn't just wasted effort. It's what Katz and Allen actually measured: teams that stop taking in outside information get worse over time, and they don't notice because the feedback that would tell them has been filtered out.

There's also a flip side worth using. This bias can work for you if you understand it. If you need a team to adopt an outside idea, hand it to them early and let them shape it. The moment they've adapted it, it stops feeling external. Some companies have flipped the phrase entirely and talk about ideas as "proudly found elsewhere." Same bias, pointed in a useful direction.

The goal isn't to distrust your own team's work. It's to notice when the source of an idea is doing the evaluating instead of you.


🎯 Here are some key takeaways

1️⃣ Separate the source from the substance: When your team pushes back on an idea, ask one question before anything else: would we react the same way if we’d come up with this ourselves? If the honest answer is no, the rejection is about origin, not quality. That doesn’t mean the idea is good. It means you haven’t evaluated it yet. Write down the actual objections, strip out any reference to where the idea came from, and see what’s left. Often the list gets very short. Sometimes it disappears entirely.

2️⃣ Watch your team’s boundaries, not just your company’s: External doesn’t only mean outside the building. An idea from engineering can feel foreign to design, and vice versa. Research from another squad can get the same skeptical treatment as research from a vendor. Pay attention to which suggestions get a fair hearing and which get a polite “interesting” followed by nothing. If the pattern lines up with who suggested it rather than what was suggested, you’ve found the bias at work.

3️⃣ Make outside ideas feel owned before you ask for adoption: The research on countermeasures points to perspective taking as one of the more effective tools. In practice, that means involving the receiving team early enough that they help shape the thing they’ll be adopting. A design system component that a squad helped test feels different from one that landed in their backlog. The idea doesn’t change. The sense of ownership does, and that’s what the bias responds to.

4️⃣ Treat “build vs. adopt” as a real decision with real criteria: Building in-house is sometimes correct, especially for the parts of your product that define it. Spolsky’s defense of Not Invented Here holds up for core work. The failure is when “let’s build it ourselves” is the default rather than the conclusion. Before a rewrite or a custom solution, state in writing what the existing option fails to do. If the strongest argument is “we’d understand it better,” that’s a comfort preference, not a product requirement.

5️⃣ Audit how much outside input your team actually takes in: Katz and Allen’s finding was that long-tenured teams stopped communicating outward and then stopped improving. Check your own intake. When did your team last change a decision because of research it didn’t run, a pattern it didn’t invent, or feedback from a discipline it doesn’t belong to? If you can’t remember, the filter has probably closed without anyone deciding to close it. Rotating who brings in external references, and rewarding it when they do, keeps it open.


Explore the full Cognition Catalog

There is much more to explore. Stay tuned for a new bias every other week!

Availability Heuristic

Suggestibility

False Consensus

​

The Beyond UX shop is open!

Get FREE shipping on all US orders over $30!

There's More to UX than Design Print

Vast and Endless Sea Print

Cognition Catalog Index Print

​

You iterated, pivoted, circle-backed, and made it out of Q4 (barely).

You’ve earned a Merit-ish Badge!

Choose from four sets:
​
• Soft Skills, Sharp Tongue
• Cult of Figma Initiation
• Pixel Pusher Survivor Kit
• Field Notes & Frayed Nerves

​

They don't teach this stuff in school

Learn the things they left off the syllabus.

Also available at these fine retailers

​

Copyright Š 2023 Beyond UX Design
All rights reserved

717 Philadelphia Street, , Covington, KY 41011

​Unsubscribe // Preferences​

Join 10,000+ designers improving their soft skills, weekly!

Beyond UX Design's mission is to give you the tools you need to be a truly effective UX designer by diving into the soft skills they won't be teaching you in school or a boot camp. These skills are critical to your success.