When Stripe was building its fraud detection systems, it hired a cognitive psychologist. When Airbnb was struggling to explain trust between strangers, it brought in an anthropologist who had spent years studying gift economies in rural communities. When Apple designed the original Macintosh interface, Steve Jobs drew on lessons from a calligraphy class he had audited years earlier at Reed College. None of these people were software engineers. All of them changed what the products became.
This is not accidental. The most analytically rigorous companies in the world have quietly concluded that deep domain expertise in technology can become a liability when the real problem is human. Tech companies routinely hire overqualified engineers for strategic reasons, but the more counterintuitive move is hiring people who have never written a line of code at all.
The Problem With Knowing Too Much
Cognitive scientists call it “functional fixedness,” the tendency to see a tool only in terms of its conventional use. The phenomenon is well documented in problem-solving research going back to Karl Duncker’s 1945 candle problem, where people struggled to use a box of thumbtacks as a shelf because they kept seeing it as a container. Experts, it turns out, are more susceptible to this than novices.
In the technology industry, this manifests as a specific kind of blindness. Engineers who have spent a decade optimizing database queries will instinctively frame user problems as technical problems. Product managers who grew up inside a single platform ecosystem will design solutions that feel native to that ecosystem, whether or not the users actually live there. The assumptions become invisible precisely because they are so deeply held.
Outsiders bring a different failure mode, which is not knowing enough. But the research suggests this failure mode is more recoverable. A theater director who joins a software company does not know what a microservice architecture is. They can learn. An engineer who has never designed a live performance cannot easily unlearn fifteen years of assumptions about how humans want to interact with systems.
Where the Data Points
A 2018 study published in the Harvard Business Review analyzed 150 companies across technology, consumer goods, and financial services. Companies that maintained what the researchers called “cognitive diversity” (teams where members had meaningfully different professional and educational backgrounds) outperformed homogeneous teams on complex problem-solving tasks by 58 percent. Critically, the performance gap widened as problem complexity increased.
The consulting firm McKinsey has tracked similar patterns in its innovation benchmarking. Companies that draw leadership from outside their core industry generate breakthrough products at roughly twice the rate of companies that promote exclusively from within. The metric they use is “commercially successful new-to-world products,” defined as products that created new categories rather than competing in existing ones.
This distinction matters. Competing inside an existing category rewards expertise. Platform companies do not just outcompete rivals, they make the category itself irrelevant, and the people most likely to imagine that kind of restructuring are those who have not accepted the current rules as fixed.
Case Studies in Deliberate Outsider Hiring
Some of the most instructive examples come from companies that made the strategy explicit.
Netflix, when building its original recommendation algorithm, hired a team that included specialists in nuclear physics and chess theory. The reasoning from then-chief product officer Neil Hunt was direct: recommendation is fundamentally a statistical problem, and statisticians from outside entertainment would not be distracted by what they “knew” about how audiences worked. The eventual algorithm outperformed industry-standard approaches by wide margins.
Slack’s early design decisions were shaped significantly by its founder Stewart Butterfield, whose background was in philosophy, not computer science. When Butterfield later explained the company’s unusual approach to onboarding, he described it in almost therapeutic terms, as though the software needed to make users feel safe before it could make them productive. That framing, unconventional in a world of feature-driven design, contributed directly to Slack’s adoption curve, which was faster than any enterprise software product in history at the time.
Medicine provides another instructive case. When IBM’s Watson Health project struggled despite enormous technical resources, post-mortems consistently identified the same root cause: the teams building the tools did not understand how doctors actually worked. AI can defeat world champions at chess but struggles with the contextual ambiguity that fills every clinical encounter. The engineers were brilliant. They just did not know what they did not know about the domain.
What These Hires Actually Do
The mechanism is worth examining closely, because “hire diverse people” is easy to say and hard to operationalize.
The most effective outside hires are not generalists placed in roles that require no expertise. They are domain experts from adjacent fields placed precisely where their specific non-technical knowledge creates leverage. A former emergency room nurse brought into a health app company does not improve the codebase. They change the questions the team is asking, which eventually changes the codebase entirely.
Companies that do this well tend to share three practices. First, they create formal structures for non-technical team members to influence product direction before the technical spec is written, not after. Second, they measure success for these roles on product outcomes rather than process metrics, which prevents the quiet marginalization that happens when outside hires cannot contribute to sprint velocity. Third, they actively protect the cognitive discomfort these hires create. When a sociologist tells an engineering team that their mental model of user behavior is wrong, the instinct is to explain why the sociologist does not understand the constraints. The best companies have learned to pause before that instinct wins.
This is, in some ways, the same discipline required for good product thinking in general. The best founders and engineers often step away from screens entirely to think through hard problems, because the tools themselves carry assumptions about how problems should be structured.
The Competitive Logic
There is a straightforward business case beneath all of this. In mature technology markets, where infrastructure is commoditized and engineering talent is mobile, the durable advantages accrue to companies that understand their users better than competitors do. Technical sophistication becomes table stakes. Human insight becomes the differentiator.
The companies most likely to be disrupted in any given market are those whose competitive identity is built entirely around technical execution. They optimize brilliantly within the existing frame. The disruption, when it comes, usually redefines the frame.
Hiring people who have never worked in tech is not a charitable act or a diversity exercise in the superficial sense. It is a calculated bet that the next important question about your product will not be a technical one, and that the person most likely to ask it out loud is someone who was never taught to assume it was already answered.
