ExpertsFMHow ARM Became The World’s Default Chip Architecture (with ARM CEO Rene Haas)
ACQ2 by Acquired · December 2, 2024
5 Selected Lessons:
heuristic · 2 framework · 1 case · 1 reasoning_pattern · 1
Shared-success licensing model (license fee + royalty)
Source
ACQ2 by Acquired — How ARM Became The World’s Default Chip Architecture (with ARM CEO Rene Haas) (December 2, 2024) · at 24:43 ▸ · at 39:44 ▸
When this applies
when you have valuable IP/R&D that customers would otherwise have to replicate themselves, and you want broad adoption without being the bottleneck
The takeaway
Price your offering so the customer's upfront cost is lower than their alternative cost of building it themselves, and capture your upside later, proportional to their success.
Why it works
A modest upfront fee acts as a proxy for R&D the customer avoids spending, while a back-end royalty aligns the licensor's success with the customer's shipped volume, removing the need to compete as a vertically integrated manufacturer.
One level up
Align your incentives with your customers' outcomes rather than extracting maximum value upfront.
Where it stops holding
This stops working when the ecosystem/tooling needed to integrate a licensed design doesn't yet exist, or when there's no way to meter/verify shipped volume for royalties.
Detail
procedure:
- Charge a modest upfront licensing fee as a proxy for R&D the customer saves
- Take a royalty on production volume so upside is shared
- Avoid exorbitant upfront pricing so it's not money the customer wouldn't spend anyway
benchmarks: {"early revenue mix":"licensing revenue >> royalty revenue until customers reach volume"}
rationale: Removes the need to out-compete vertically integrated incumbents directly; instead makes it economically attractive for them to adopt your design.
In their words
I'm gonna have a business model that's going to require an upfront licensing fee, is modest, and I'll take a royalty when you ship in production.
Inference-vs-training ratio argument for CPU relevance amid GPU hype
Source
ACQ2 by Acquired — How ARM Became The World’s Default Chip Architecture (with ARM CEO Rene Haas) (December 2, 2024) · at 59:43 ▸
When this applies
when a core, less glamorous component is dismissed as obsolete because a flashy complementary technology is getting all the attention
The takeaway
When a flashy new technology (the 'accelerator') gets all the attention, check whether the overlooked complementary component ('the engine around it') actually captures more cumulative volume because its use case recurs continuously downstream.
Why it works
Training is a one-time, concentrated workload performed by relatively few large systems, while inference is a continuous, distributed workload that must run everywhere training's outputs get used — so the volume of inference work (and the CPUs needed to orchestrate/run it, especially at the edge) mathematically dwarfs training, making the 'complementary' component actually the larger long-term opportunity.
One level up
Don't mistake a component's lack of glamour for lack of long-term market importance — follow the downstream multiplication of use, not the upstream novelty.
Where it stops holding
This stops working when the 'teacher' (training) workload itself scales faster than the 'student' (inference) deployment, or when inference consolidates onto the same accelerator hardware rather than needing separate CPU-class compute.
Detail
approach: Separate a technology stack into 'teacher' (training, concentrated) and 'student' (inference, distributed) roles and count where the actual compute-unit volume accumulates over time.
signals:
- New accelerator technology gets disproportionate attention/investment
- The underlying component (CPU) is framed as a 'known quantity' or commodity
- The downstream use case (inference) recurs across many more devices/instances than the upstream one (training)
rationale: If training is the teacher, inference is the student — there are far more students than teachers, so inference workloads (running on CPUs/edge devices) will vastly outnumber training workloads.
In their words
If training is the teacher, inference is the student. And there are far more students than teachers in the universe, that's why there'll be far more inference workloads than than training.
10x-ish switching cost threshold for architecture change
Source
ACQ2 by Acquired — How ARM Became The World’s Default Chip Architecture (with ARM CEO Rene Haas) (December 2, 2024) · at 19:13 ▸
When this applies
when deciding whether to abandon an entrenched technology platform despite high switching costs
The takeaway
Switching an entrenched standard requires an improvement large enough to dwarf the switching cost — incremental gains (e.g., 10-15%) are insufficient.
Why it works
Software/ecosystem lock-in creates a high fixed cost to switch; only a large enough performance/cost/power delta can justify paying that cost, because a marginal improvement doesn't offset migration pain.
One level up
Entrenched standards are sticky by default; disruption requires asymmetric advantage, not marginal improvement.
Where it stops holding
This stops working when there is no existing software ecosystem to lock in (e.g., a brand-new product category), in which case even small advantages can determine the winner.
Detail
rule: To overcome software lock-in and switch CPU architectures, you need a 'fairly large paradigm shift' in power, cost, or performance benefit — not a 15% improvement.
threshold: People talk about needing 10x advantage; Haas says maybe not exactly 10x, but 'not 15%' — must be material.
rationale: Switching costs are dominated by software and ecosystem investment, which only a large enough benefit can justify abandoning.
In their words
You know, people will talk about you need the 10 x advantage to make the switch. I'm not sure it's 10 x, but it's not 15%.
Never allow custom instructions that break ISA compatibility
Source
ACQ2 by Acquired — How ARM Became The World’s Default Chip Architecture (with ARM CEO Rene Haas) (December 2, 2024) · at 39:44 ▸ · at 42:40 ▸
When this applies
when managing a shared standard/platform where individual participants might want custom extensions for competitive edge
The takeaway
Preserve the single compatibility layer that makes your standard valuable, even if it means forgoing apparent customer-requested differentiation — ecosystem compatibility has more aggregate value than any individual optimization.
Why it works
If different licensees add incompatible custom instructions, software developers can't rely on any instruction being universally present, so they default to the lowest common denominator — destroying the value of those customizations and fragmenting the ecosystem that makes the standard valuable in the first place.
One level up
The core asset of a platform business is the integrity of its shared standard; protect it even against the preferences of your biggest customers.
Where it stops holding
This stops working when the standard is not widely enough adopted for compatibility to matter, or when a segment is isolated enough (no shared software ecosystem) that fragmentation costs nothing.
Detail
rule: Architecture licensees can build their own implementation but are never allowed to add custom instructions that others don't have.
rationale: Once instructions differ across implementations, software can't reliably use them, forcing lowest-common-denominator software and destroying the architecture's unifying value.
In their words
We're never gonna break the ISA. We're not going to allow people to add custom instructions because once you do that, you break software compatibility, which is one of the superpowers of ARM.
IBM PC's open architecture decision locking in x86/CISC for decades
Source
ACQ2 by Acquired — How ARM Became The World’s Default Chip Architecture (with ARM CEO Rene Haas) (December 2, 2024) · at 15:57 ▸ · at 19:13 ▸
When this applies
when an incumbent enters a new product category under time pressure and decides to outsource core components rather than build in-house
The takeaway
The architecture that first attracts broad, cheap replication and a software ecosystem wins the long-run standard, even if a technically superior alternative exists — because stickiness comes from accumulated software investment, not raw technical merit.
Why it works
By outsourcing the processor (Intel) and OS (Microsoft) instead of building in-house, IBM enabled third-party clone makers to replicate the platform cheaply, which rapidly built a massive software base on that architecture — and once software accumulated, switching away became prohibitively costly for the whole industry, regardless of whether a technically superior alternative (RISC) existed.
One level up
In platform markets, speed-to-ecosystem beats technical superiority as a long-term moat.
Where it stops holding
This stops working when the open/cloned platform fails to build enough software volume before a superior closed alternative achieves critical mass itself.
Detail
situation: IBM, the vertically-integrated mainframe leader, entered the home-computer market late and needed to move fast; it chose not to build its own processor or OS.
decision: IBM selected Intel's 8086 (over Motorola) and Microsoft DOS (over Gary Kildall's CP/M), making the platform 'open' enough for clone makers (Compaq, Dell, Gateway) to replicate.
outcome: x86/CISC became the de facto standard for the PC era despite RISC being, in Haas's view, probably technically better, because software accumulated on x86 and created massive switching costs.
lesson: A technically inferior but open, cloneable architecture can out-compete a superior closed one by winning the software/ecosystem race first.
In their words
This is what created the birth of not only the IBM PC platform, obviously, but the Intel x 86 architecture. And that's why as a default, CISC end quote, because that's what x 86 was, is the de facto. It really wasn't a, oh, risk was better because it probably was, but kinda didn't matter.