Picture a room full of engineers debating which database to use. The conversation is technical, detailed, and completely beside the point. The database that will actually win the organization isn’t necessarily the fastest or the most elegant. It’s the one with the best documentation, the most Stack Overflow answers, and the vendor with a sales rep who shows up to the meeting.
This isn’t cynicism. It’s one of the most consistent patterns in tech history, and understanding it changes how you think about building products and placing bets.
The Evidence Is Overwhelming
Betamax was a better recording format than VHS by most technical measures. The picture quality was sharper, the cassettes were smaller. VHS won because JVC licensed it aggressively, the tapes were cheaper to manufacture, and the longer recording time (even at lower quality) matched how people actually used the product: recording football games and movies.
The same story plays out in software. OS/2 was, by most accounts, technically superior to Windows 3.1. IBM had built something genuinely more stable and capable. Microsoft had distribution through PC manufacturers and a developer ecosystem IBM couldn’t match. Windows won.
TCP/IP displaced technically sophisticated alternatives because it was simple enough for anyone to implement. The internet wasn’t built on the best networking protocol. It was built on the one that spread.
More recently, JavaScript has conquered server-side development despite being a language with well-documented quirks that have driven developers to drink for decades. Node.js didn’t win because JavaScript is the ideal language for backend systems. It won because there were already millions of JavaScript developers, and the barrier to trying it was zero.
What “Winning” Actually Requires
The pattern here isn’t random. Markets don’t evaluate technologies the way engineers do. Engineers ask: what’s the best solution to this technical problem? Markets ask something messier: what can I actually deploy, staff for, debug at 2am, and hand off to someone else?
Distribution matters more than quality past a certain threshold. Once a technology is good enough, the marginal improvement from being technically superior is often worth less than the practical benefits of being widely adopted. Documentation, community, tooling, training pipelines, and support ecosystems are all part of what a technology actually is in practice. A technically inferior tool with a thriving community is a better choice for most organizations than a technically superior one with sparse documentation and three contributors on GitHub.
This is why the “best” solution in a controlled benchmark is rarely the best solution in a real organization. Organizations are messy, staffed by people with varying skill levels, constrained by existing infrastructure, and subject to political pressures that have nothing to do with query latency.
The second-best technology, if it has better network effects, usually delivers more value in aggregate. That’s not a failure of the market. That’s the market correctly pricing all the things engineers forget to price.
Why Engineers Keep Getting This Wrong
Engineers are trained to optimize for correctness and performance. The instinct is to find the best tool for the job. This is valuable inside a system you control. It’s misleading when predicting which technology will dominate an industry.
The cognitive trap is assuming that other people will evaluate technology the same way you do. They won’t. An IT director at a mid-sized company is not choosing between NGINX and Cadence based on performance benchmarks. They’re choosing based on what their team already knows, what their vendor supports, and what they can get budget approval for.
Startup founders fall into this trap constantly. They build something technically superior to the incumbent and expect the market to notice. Sometimes it does. More often, the incumbent wins on inertia, distribution, and ecosystem, even after the startup has built a genuinely better product. The history of enterprise software is littered with technically excellent companies that lost to Oracle.
The Counterintuitive Lesson for Builders
If you’re building a product, this pattern carries a direct implication: being technically second-best is often a more viable position than being first-best with poor distribution. A product that’s 80% as capable but five times easier to integrate will usually beat the superior alternative in the market.
This isn’t an argument for building mediocre products. The technical floor still matters. What falls below “good enough” loses. But above that threshold, resources spent on documentation, onboarding, ecosystem development, and partnerships frequently generate more market share than equivalent resources spent on technical improvement.
The teams that internalize this build differently. They invest in API design early. They write documentation before it’s requested. They think about what happens when a junior developer at a customer’s company has to debug something at 11pm without any help. They optimize for the experience of the whole ecosystem, not just the benchmark.
There’s a related point worth sitting with: being technically second also means you can learn from what the first-best got wrong. VHS watched Betamax’s stumbles. JavaScript’s server-side entrants watched what made Ruby on Rails popular and what made it painful at scale. The technically second entry often has a clearer picture of what users actually need, because it had more time to watch people struggle with the alternative.
What to Do With This
If you’re evaluating which technologies to bet on, weight ecosystem health heavily. How active is the community? How good is the documentation? How many companies are hiring for this skill? These aren’t soft factors. They’re the actual determinants of whether a technology survives contact with real organizations at scale.
If you’re building, take the distribution problem as seriously as the technical problem. The best product that nobody can figure out how to deploy is a worse product than you think it is. And if you’re an engineer frustrated that your technically superior proposal keeps losing internal debates, the issue probably isn’t that your colleagues are irrational. It’s that they’re correctly weighting factors you’re dismissing as non-technical.
The market isn’t broken. It’s just solving a different problem than the one you’re benchmarking.
