The Death Of Expertise

Dealing With People Who Think They Know Better

You know the type. Someone finds a blog post or watches a ten-minute YouTube video on a topic, then becomes convinced they are qualified to override someone who has spent years working in that field. This isn't a new phenomenon, but it has accelerated noticeably over the past decade. The term that keeps coming up for this is The Death Of Expertise, a concept popularized by Tom Nichols in his 2017 book, though the behavior itself is far older than the label. Here is what it looks like in practice. You recommend a specific approach to something — let's say, using a headless CMS architecture for a content-heavy project. Someone responds with a link to an article they read two days ago that claims headless CMS is overhyped and that you should just use WordPress instead. The person has never built a content platform at scale. They have never dealt with content migration, API rate limits, or editorial workflow bottlenecks. But they found a source, so they consider themselves informed. I deal with this constantly in my work. A couple of years back, I was advising a client on server architecture for a mid-sized e-commerce operation. The client's CTO, who came from a generalist IT background, insisted we switch from our proposed Kubernetes-based setup to a single large virtual machine. His reasoning was that Kubernetes was unnecessarily complex for their traffic volume. He had read two articles about K8s being hard to manage. I showed him our benchmarking data, which indicated that under Black Friday load spikes, the VM would fail at approximately 3,400 concurrent users before the auto-scaling groups on the Kubernetes setup would even begin to spin up additional pods. He acknowledged the data but still pushed for the VM, arguing that "complexity costs money." We compromised on a managed Kubernetes solution, which cut the operational overhead significantly while preserving the scaling benefits. That was months of back-and-forth over a decision that should have taken thirty minutes if he had simply trusted the engineering assessment.

The Death Of Expertise In Action

The core mechanism is straightforward enough. The internet has democratized access to information, which is genuinely a good thing. But it has also created the illusion that access to information equals understanding of information. Anyone can read a Wikipedia article about quantum computing and feel equipped to discuss it at a dinner party. Reading one article about infrastructure doesn't make you an infrastructure engineer. The gap between consuming information and understanding a domain is enormous, and most people don't realize how vast that gap is. What makes this particularly frustrating is that the people exhibiting this behavior are usually confident, not hesitant. They don't approach the conversation with the posture of someone seeking to learn. They approach it with the posture of someone who has already arrived. This is what Nichols identified as the central problem: expertise has been culturally delegitimized in ways that make rational discourse about technical decisions nearly impossible. There is a counter-intuitive element here that most people miss. The Death Of Expertise is not primarily a problem of ignorance. It is a problem of selective confidence. The people involved are not uniformly stupid. They are often intelligent, well-read, and genuinely capable of understanding technical concepts. What they lack is the tacit knowledge that comes from experience — the kind of thing you pick up by making mistakes over time. They have the map, but they have never walked the territory. And they don't know that they don't know that.

Another thing beginners in this space don't always grasp: the Dunning-Kruger effect is often cited as the explanation, but it is an incomplete one. The Dunning-Kruger effect describes people with low ability overestimating their competence. That's part of it. But The Death Of Expertise also affects people who are genuinely competent in their own field and then apply that same confidence blindly to unfamiliar territory. A brilliant lawyer may aggressively challenge an epidemiologist's pandemic advice because they understand argumentation and evidence in their domain and assume the mechanics transfer directly. They don't. Different domains require different epistemologies — different ways of knowing things that are true. So what do you actually do when you encounter this? I have developed a few practical approaches over the years, and none of them are particularly satisfying. Lead with constraints, not conclusions. When someone challenges your recommendation, don't just restate the recommendation. Explain the constraints that shaped it. Budget, timeline, team skill level, future scalability requirements, technical debt tolerance — list them out. People who reject expertise are often responding to the conclusion without having seen the reasoning that produced it. Once they see the constraints, they either accept the logic or they reveal their own hidden constraints, which is actually useful information. In the server architecture situation I mentioned, the client's real concern wasn't technical. It was budget predictability. They feared surprise costs from managed Kubernetes pricing. Once we laid out the cost model transparently, the objection softened considerably. They weren't wrong to care about cost. They were just attacking the wrong part of the solution.

Ask for their alternative, specifically. When someone says your approach is wrong, ask them to propose the alternative they want instead, including how it handles the specific edge cases your approach addresses. Most people cannot do this. They will say "just use the simpler thing" without being able to articulate how the simpler thing handles eight simultaneous regional outages or GDPR data residency requirements. The act of asking for specifics often causes the objection to evaporate, because the person hasn't actually thought through the alternative. This isn't a trick. It is a diagnostic. You are determining whether the disagreement is substantive or performative. Know when to disengage. There is a limit to how much energy you can expend convincing someone who has decided that their reading of a blog post trumps your years of experience. If you have explained the constraints, presented the data, and addressed the specific objections, and the person continues to argue from a position of generalized distrust of experts, you are no longer having a technical discussion. You are having a social one, and you will not win it. Document your recommendation in writing. State your concerns. Then move on. This happened to me with a different client who insisted on building a custom search engine instead of using a purpose-built solution like Algolia. I presented three comparable case studies where custom search implementations failed under production load. They proceeded anyway. The custom search broke within six months of launch. I did not say "I told you so." I just updated the incident report to note that the original recommendation had been overridden and documented the failure mode. There are real limitations to everything I have described here. Leading with constraints assumes the other party is willing to engage with constraints. Some people are not. Asking for a specific alternative assumes the person has the cognitive capacity to construct one. Some don't. Disengaging assumes there is someone else who can make the final decision. Sometimes there isn't. These strategies improve your odds. They do not guarantee a different outcome. If you are in a position where you are the sole technical authority and the non-technical stakeholders are determined to ignore you, no amount of communication technique will fix that. You need structural changes — a different reporting line, a different project governance model, or in extreme cases, the realization that the project is not going to succeed and deciding whether you want to be associated with that outcome.

One more thing worth noting: the reverse side of The Death Of Expertise is also real. Some professionals respond to this cultural shift by becoming overly deferential, softening their recommendations to avoid conflict, or hedging their language so much that their actual expertise becomes invisible. If you say "we could potentially consider exploring" instead of "this is the right approach because," you are not being diplomatic. You are making it easier for someone to dismiss you. There is a difference between communicating clearly and diluting your position to make it palatable to people who are predisposed to reject it. Clear, confident communication rooted in evidence is the better strategy. "Here is what I recommend and here is why" is more effective than "Here are some possibilities, take your pick." The Death Of Expertise is not going away. It is a structural feature of how information flows in a networked society, and it will likely intensify as AI tools make it even easier for anyone to generate plausible-sounding technical advice without understanding any of it. The best response is not frustration. It is a systematic approach to communicating expertise in a way that makes the expertise visible, testable, and difficult to dismiss on superficial grounds.