The Standard That Refused to Die
You are the engineer. It's 1986, and you are typing commands into a terminal, moving files between machines over a protocol that everyone in the room agrees is temporary. Functional, slightly clunky, and almost certainly on its way out. A better thing is coming. Everybody says so. Forty years later, that protocol is still running, not metaphorically, but literally, inside data centers and enterprises and the infrastructure of companies whose founders weren't born when the standard was ratified.
This is the central puzzle of technological lock-in. Dominant standards don't just persist. They petrify. And the lifespan of a winning standard tells you something uncomfortable about how technology actually evolves, which is far less like a river and far more like a concrete pour.
Why Winning Feels Permanent Once It Happens
Most people misread the mechanism entirely. They assume a standard persists because it's the best available option. Sometimes that's true. More often, it persists because switching costs compound in a way that becomes almost impossible to reverse once you're three or four layers deep, and by then the question of which option is "best" has become largely academic.
Here's how it works in practice. A company adopts a data interchange format, say an early version of a proprietary spreadsheet structure, because it's what their suppliers use. Their suppliers use it because their enterprise software was built around it a decade earlier. That software was built around it because the original developers needed to ship quickly and the format had the widest tooling support at the time. Nobody in this chain made a bad decision. Each actor was entirely rational given the information they had. The result is a dependency graph that looks, from the outside, like loyalty, but is actually just accumulated switching cost.
Economists call the underlying force "network externalities." The more users a standard has, the more valuable it becomes to each individual user, not because the standard improves, but because the ecosystem around it deepens. More tools. More trained personnel. More documentation. More integrations. Each new layer adds value and simultaneously raises the exit price for anyone contemplating a move.
The result: a standard that reaches critical mass tends to have a lifespan measured not in product cycles but in generations. COBOL, the programming language designed for business computing, was declared obsolete so many times that the declarations themselves became a running joke among mainframe administrators. Estimates from financial regulators have suggested that a substantial portion of the world's daily financial transactions still pass through COBOL-based systems. Not because the language is elegant. Because the cost of rewriting those systems, training new staff, and validating every edge case in decades of accumulated business logic is genuinely enormous, and no executive wants their name on the project when it fails.
The Geometry of Switching Costs
Switching costs don't grow linearly. They grow geometrically, because a standard doesn't just accumulate users. It accumulates secondary markets, tertiary integrations, and institutional memory, each layer calcifying over the last like rings in old timber.
Consider a worked scenario. A mid-sized logistics firm adopted an EDI (Electronic Data Interchange) messaging standard in the early 1990s to communicate shipment data with retail partners. Over the following decade, they built internal tooling on top of it, hired staff who specialized in it, and wrote contracts that specified it by name. By the time a genuinely superior XML-based alternative existed, the firm faced a choice that wasn't really a choice: spend eighteen months and several million dollars rebuilding every integration, retraining every operations analyst, and renegotiating contracts with forty-seven retail partners, or keep using the old standard and patch around its limitations. They patched. They are probably still patching.
This is why the lifespan of a dominant standard almost always surprises the people who study it. In 1984, a researcher might have estimated that token ring networking had a decade of relevance before something better arrived. Something better did arrive. Token ring lasted another fifteen years in pockets of the enterprise market, precisely because the firms using it had already built their facilities, trained their people, and amortized their equipment costs against a timeline that didn't include a forced migration.
Every year a standard persists, the switching cost grows, which makes it more likely to persist another year, which grows the cost further. It's a ratchet, not a pendulum.
What People Get Wrong About Disruption
Lock-in is not absolute. The catch: the popular narrative about disruption gets the mechanism exactly backwards, and it has misled a great many product strategists into betting on the wrong variable.
Conventional wisdom says that a sufficiently superior technology will always eventually displace a dominant standard. The evidence is mixed at best. What actually displaces entrenched standards, when they are displaced, is rarely pure technical superiority. It's usually one of three things: a regulatory intervention that changes the cost calculus overnight; a generational shift in the workforce that removes the human carriers of institutional knowledge about the old system; or a platform shift so fundamental that the old standard becomes physically irrelevant rather than merely inferior.
The transition from analog to digital telephony wasn't won by a better codec. It was won because regulators restructured the industry and because the physical infrastructure required replacement anyway. The transition away from floppy disks wasn't won because USB drives were obviously superior. It was won because Apple shipped a consumer computer with no floppy drive and forced the industry's hand.
Standards don't usually die from competition. They die from context collapse, when the world around them changes so thoroughly that the switching cost becomes irrelevant because the old platform no longer connects to anything worth connecting to.
So ask yourself: if you are betting on a new standard's eventual dominance, the question isn't whether your format is better. It's whether you can survive long enough, and accumulate enough ecosystem depth, to become the thing everyone else is locked into.
The Institutions That Live Inside the Standard
There is a final layer that almost never gets discussed, and it is the most revealing one.
A dominant standard doesn't just create switching costs in software and hardware. It creates switching costs in people. A generation of developers, administrators, accountants, and logistics coordinators builds their entire professional identity around a standard. Their certifications reference it. Their resumes feature it. Their mental models of how problems get solved are structured around its particular affordances and limitations.
This matters more than almost any technical consideration. When IBM's mainframe architecture became the dominant enterprise computing standard, it didn't just capture market share. It captured a workforce. The people who understood it deeply had enormous incentive to keep it relevant, to train successors, to argue for its continued procurement. They were, in a very practical sense, the standard's immune system, and immune systems fight hard.
This is why the lifespan of a dominant corporate standard is ultimately a story about institutions more than technology. The standard becomes a container for accumulated human knowledge, organizational habit, and professional identity. Replacing it means replacing all of that simultaneously, which is a social project of a different order than a software migration.
The engineer from 1986 eventually retired. But she trained someone, who trained someone else. And the protocol she used is still running.
The next time someone tells you a dominant standard is on its way out, the right question isn't whether the replacement is better. It's whether anyone has figured out what to do with the careers, the contracts, and the forty years of accumulated workarounds built inside the old one. Nobody ever has a clean answer to that. Which is precisely why the old standard is usually still running when they ask.