The Silence Behind "Why Don't You Use...?"
Engineers at large technology companies frequently field the question, "Why don't you use technology X?" The X in question can be anything from an application to a programming language to a whole processor architecture. To the outsider, the lack of a clear public answer often seems like ignorance or stubbornness. In reality, the decision not to adopt a technology is rarely simple or spontaneous. It is typically the result of an internal evaluation involving multiple teams, culminating in a combination of reasons that the company has no interest in broadcasting.
Technology choices can fail for a wide range of valid reasons. A product might perform poorly, be too expensive, lack critical features, be poorly documented, or come with serious bugs. Other times, the issues are deeper: a problematic license, an uncertain company future, or a tool built without genuine subject matter expertise. There are also cases where a custom internal solution is simply good enough, or where the technology made sense a decade ago but has since been outpaced.
The Three Categories of Rejection
Understanding why a company won't adopt a technology usually means navigating a spectrum of unspoken reasons, which can be grouped into three general classes.
Private reasons are confidential by nature. This includes situations where a company knows of a better solution under a non-disclosure agreement, or where they have learned of serious defects that cannot be discussed publicly. Often, a decision is based on internal roadmaps, special pricing, or future product plans that are considered competitive knowledge. In one notable example, a company was interested in a technology, only to have its own CEO, under NDA, admit he was abandoning the project—information that was not yet public.
Complicated reasons are technically valid but difficult to explain without significant time and context. For instance, a major internet company might stick with FreeBSD for its CDN not out of stubbornness, but because regular production tests show it's simply faster for that specific workload than Linux. Another common scenario is discovering that a product was developed by a team without prior domain experience—a subtle but fatal flaw that is hard to articulate, especially to the developers themselves, who lack the background to see where they went wrong. At smaller companies, the reason might be that the cost of switching—engineering time, technical debt, security risk—outweighs any potential benefit, making the existing, "good enough" solution the rational choice.
Rushing an explanation is a risk. Answering with a weak, poorly-formulated reason is often worse than saying nothing. It gives advocates of the rejected technology an easy target to attack with more time and energy than your team has to defend, putting the company in a worse public position than if it had remained silent. For this reason, many companies opt to discuss only the safer, objective reasons, like poor documentation or a lack of debugging tools. While easier to discuss, these are rarely the whole story, and focusing on them can be misleading. If those safe issues get fixed, there can be a public expectation that the company will finally switch, which may not happen given the other, unspoken reasons for the decision.
The much-cited "bad reasons" for a tech choice—such as "not invented here" syndrome, corporate politics, or simple ego—are believed by outsiders far more often than they are the actual cause. At large companies with deep reservoirs of expertise, most technical decisions have sound justifications, even if those justifications are confidential. In the author's experience from inside such a company, the poor-choice scenarios people imagine happen perhaps a tenth as often as they assume.
Finding the Truth
It's easier to say what you do use and why, than what you don't use and why not.
The only sure way to get the real reason behind a rejection is to join the company and ask the right team directly. If that's not an option, the questioner must be more strategic. Instead of asking "Why not X?", ask safer, more neutral questions that can rule out ignorance: "Are you aware of technology X?" or "Are you aware that technology X claims to be faster at Y?".
The initial list of reasons also misses some practical realities noted in subsequent discussions. A lack of in-house expertise can make hiring difficult, and the cost of migrating from an existing system often eclipses the benefits of a new one. Legacy code and infrastructure can create enormous inertia. Finally, many of these inquiries are less about genuine curiosity and more about the questioner advertising a technology they have a vested interest in—a dynamic that does little to encourage open, honest dialog. As the author learned from being on the outside, the silence from large companies wasn't a sign of ignorance but a considered response to a complex set of constraints.
