Technology bets
Which architecture or technical approach should we bet on?
Choosing an architecture, platform, language, process or technical approach that is expensive to reverse.
43
64%
19%
17%
What the cases suggest
Technology bets are the largest group and among the most successful, but that partly reflects which technologies the essays were written about: the record follows architectures that became foundations. The clearest repeated lesson is about compatibility. AMD’s 64-bit extension of x86 beat Intel and HP’s clean break with Itanium; TypeScript added to JavaScript rather than replacing it; IBM’s System/360 made a whole range run the same software.
What separated the decisions that worked
- Bets that kept existing users’ code and habits working generally beat bets that asked everyone to start again.
- Small working systems beat grand designs: Unix after Multics, the web after Xanadu, time-sharing demonstrated on a modest machine.
- Leaders’ failures came from betting on a future that required others to follow them (OS/2, Itanium) or from setting technical targets too ambitious for their tools (Intel’s 10-nanometre process).
Where this evidence is weak
Survivorship is strongest here. Thousands of technical bets that went nowhere never got an essay, so the success rate in this group should not be read as the odds of a technical bet succeeding.
By who decided
| Decision-maker | Cases | Paid off | Mixed | Backfired | Too early |
|---|---|---|---|---|---|
| Market leader | 16 | 10 | 2 | 4 | 0 |
| Challenger | 3 | 3 | 0 | 0 | 0 |
| Young company | 5 | 4 | 0 | 1 | 0 |
| Industry-wide | 4 | 0 | 3 | 1 | 0 |
| Researchers and communities | 14 | 9 | 3 | 1 | 1 |
| Public body | 1 | 1 | 0 | 0 | 0 |
The cases
Each links to the essay, memo or road not taken where the decision is described and judged, with its sources.
- Store the program in memory alongside the data Turning a fixed capability into data makes it general, at a cost in efficiency that time usually repays.
- Put capacity and intelligence in the network: small cells, reused frequencies, simple handsets If the scarce resource cannot be increased, redesign the system to reuse it.
- Treat the compiler’s efficiency, not the language design, as the real challenge Find the single objection that stops adoption and make it disappear; elegance can wait.
- Demonstrate time-sharing with a modest system that ran alongside batch work Make the first version compatible with how people already work, and small enough to finish.
- Make an entire range of computers run the same software (System/360) A compatibility promise can be worth more than any single product; once made, it shapes everything after it.
- Use the machine’s instruction set as the interface, giving every user a complete virtual copy of the computer The best interface is often one that already exists; virtualise it instead of inventing a new one.
- Leave the ambitious Multics project and build a small system, Unix Scope down until it is cheap enough to finish, then let a community extend it.
- Protect users from knowing how data is stored (the relational model) A stable interface that says nothing about implementation can absorb fifty years of change.
- Build a programmable processor instead of custom calculator logic When the platform improves automatically, general solutions beat custom ones.
- Combine the Air Force and Navy concepts into one system with atomic clocks on the satellites and receivers that only listen, so that any number of users could share it A system that costs nothing extra for each new user is ready for uses its designers never imagined.
- Let the database choose how to run each query using statistics about the data An abstraction is only as good as the machinery that makes it fast.
- Bet on a graphical, what-you-see-is-what-you-get word processor for Windows Win the platform shift, and your format becomes the standard.
- Rebuild its system for client-server computers rather than staying on mainframes Moving to the next platform before you have to is cheaper than following after you have lost.
- Put the subscriber’s identity on a removable SIM card, and use spare signalling capacity for text messages Watch what users do with your by-products; they may be the product.
- Filter information using the reactions of other people, rather than only the content of the documents The judgements of similar people can be a better signal than the thing itself.
- Mix code into HTML pages and make deployment as simple as copying a file The easiest product to start with often wins, even if it is not the cleanest.
- Recommend products by relating items to items, computed in advance from purchase histories, rather than matching each customer to similar customers at the moment of the visit The simplest algorithm that scales often beats the best one that does not.
- Virtualize x86 anyway, with binary translation, running on top of an existing operating system Solving a problem everyone thinks requires new hardware can build a company; plan for the day the hardware arrives.
- Extend x86 to 64 bits with full backward compatibility, announced in 1999 and shipped as Opteron in 2003. When the leader leaves its customers' existing investment behind, the follower can win by protecting it.
- Back 193-nanometre immersion lithography, which images chips through a thin layer of water, and cancel orders for tools using 157-nanometre light The incremental path that works often beats the official roadmap that needs everything to go right.
- Open graphics chips to general computation (CUDA), then design chips only for neural networks (TPU) Make your product programmable; your users may find a bigger market than you designed for.
- Choose availability over consistency: an always-writeable store State your trade-off explicitly, and limit it to the problem it was made for.
- Add optional types on top of JavaScript instead of replacing it Improve the standard from inside rather than asking people to leave it.
- Package applications as portable images rather than inventing new isolation Often the winning product is the usable wrapper around capabilities that already exist.
- Describe the interface as a function of state and let the library work out the changes Declarative interfaces win when the system can handle the how reliably.
- Strip a virtual machine monitor down to the minimum so that microVMs start like processes When a trade-off is unacceptable to your customers, question whether it is real.
- Render pages on the server and hydrate only small “islands” of interactivity When the pendulum swings back, it lands somewhere new; look for what has changed since the last time.
- Store relationships as chains of pointers that programs navigate Coupling users to your internal structure buys performance now and costs flexibility later.
- Trust the programmer with memory and leave out automatic checks Trusting the expert scales with the number of experts, not the size of the code.
- Ship a scripting language in ten days that had to “look like Java” Whatever ships where everyone already is will set the standard; design it as if it will last.
- Pursue a web of machine-readable meaning built on formal standards, shared ontologies and logic, intended to be adopted broadly by publishers. A standard that asks many people to do work for a future benefit to someone else needs an immediate reward to spread.
- Ask the guest operating system to cooperate with the hypervisor (paravirtualization) Telling users the truth about the system can let them make better decisions than a perfect illusion.
- Respond to the end of Dennard scaling with multiple cores When a free improvement ends, someone inherits its cost. Plan who that will be.
- Drop SQL, joins and schemas for scale and flexibility Before abandoning a standard, ask whether the standard can absorb the fix.
- Build sites as single-page JavaScript applications Measure the cost of your choices on your users’ worst devices, not your own.
- Add the null reference because it was easy to implement Language and platform shortcuts are permanent. Choose what is safe forever over what is easy now.
- Let any program touch any part of the machine (no memory protection) Defaults that are safe in isolation become dangerous when the product is connected. Revisit them when the environment changes.
- Jointly develop OS/2 as the successor to DOS, initially targeting the Intel 80286 processor. A new platform must make the old software run well before it can make new software worth writing.
- Concentrate on a version of 1-2-3 for OS/2 rather than Windows When your business depends on a platform you do not own, keep a real option on the alternatives.
- Jointly develop a new 64-bit architecture based on explicitly parallel instruction computing, rather than extending x86. A clean break must offer gains large enough to pay for every customer's switching costs.
- Run a central index of the songs stored on users' computers, with the files themselves passing directly between users An architecture is also a legal position. Where the system keeps knowledge and control, the law will look for responsibility.
- Aim its 10-nanometre process at an unusually large increase in density, 2.7 times its 14-nanometre process, without extreme ultraviolet lithography A leader’s confidence in its own track record is the hardest risk to see from inside.
- Design hypertext as a single coordinated docuverse with two-way links, transclusion and versioning, rather than as links between independent documents. A complete design that cannot ship in pieces is a bet that the world will wait for it.
Other kinds of decision
- Opening or closing
- Business model and pricing
- Make, buy or partner
- Acquisitions and sales
- Product design
- New categories and markets
- Distribution and positioning
- Focus, exit and investment
- Trust, safety and privacy
- Executing large change
- Organisation and governance
- Public rules
Shrikant Kumar. “Technology bets.” The Telos Decision Record, Telos, version of 2026-11-03. https://shrikantk.com/record/technology-bet/