Speed of Light
The point in one sentence: benchmark every task against physics, not against competitors or your own past pace, and measure how close you are to that limit.
Adopting that one move changes how a team plans, debates, and ships.
What “speed of light” actually means
Take a task — designing a chip, closing a customer, shipping a feature, holding a meeting. Strip away every constraint that is not physics: not the org chart, not approval cycles, not “the way we usually do it,” not “we have to wait for X.” What remains is the minimum time the task could take, given only the laws of physics and the work that genuinely must happen.
That’s the speed of light. Your current pace, expressed as a percentage of it, is your speed-of-light ratio.
A canonical semis example: how fast can a wafer physically move through a fab if every machine were always ready and every test were always instant? The answer is days. The actual answer is weeks. The gap is not physics. It’s queueing, idle tools, approval gates, batch sizes. Speed of light tells you the gap is real and where to look.
Why it beats benchmarking against competitors
The standard move is to look at the field and aim to be the fastest in it. Jensen’s complaint with that, threaded through The Thinking Machine, is that the whole field can be slow together. Being ahead of Intel by six months means little if both companies are operating at 20% of speed of light. You can win the leaderboard and still leave most of the value on the table.
Speed of light removes the moving target. The benchmark is fixed by physics. You can’t grade on a curve against it.
It also flips the question. Instead of “are we good enough?” you ask “what is stopping us from being at 100%?” The second question always has a list of answers. The first one ends the conversation.
How Jensen actually uses it
The pattern, well-attested in the book and his public talks:
- An engineer brings a plan: “this will take six months.”
- Jensen asks: “what’s the speed of light?”
- The engineer either knows or finds out. Say, “six weeks, if nothing got in the way.”
- The rest of the meeting is about the gap. Where are the four-and-a-half months going? Which of those weeks are physics and which are organizational?
He’s not asking the team to actually hit speed of light. He’s asking them to know what it is. The number forces honesty about where time is going. Most of the time, the gap is coordination, batching, and waiting — not technology.
Two NVIDIA practices sit on top of this:
- Architectural cadence as a forcing function. The Hopper → Blackwell → Rubin tempo is a public speed-of-light bet. The cycle is set short on purpose so every team has to argue from physics, not from precedent.
- Mission is the boss. Once the mission (a chip, a shipment, a customer commit) has been picked, the org reorganizes around the speed-of-light path. Reporting lines bend. The work doesn’t.
How to actually compute one
The part most people skip:
- Write the task as a sequence of physical events. What atoms have to move, what data has to be computed, what bytes have to land where.
- Time each event at its physical minimum. Wafer transit, process step, compute time, network round-trip, signature, handoff.
- Sum it. That sum is your speed of light.
- Compare to current plan. The ratio is your number.
- Categorize the gap. Every missing hour falls into either “more physics we forgot” or “process / coordination / waiting.” The second bucket is where you go to work.
For non-physical work (a sales cycle, a hire, an interview round), the method is the same. Substitute “decisions that genuinely require a human to think” for the physics steps.
Where it bites
Two failure modes worth flagging before adopting it:
- Speed of light as a stick. Used badly, it becomes a tool to beat teams up for not hitting an impossible number. Jensen’s version is diagnostic. He wants the gap visible, not punished. Teams have to feel safe surfacing it honestly.
- Phantom physics. People will smuggle organizational constraints into the speed-of-light estimate to make the gap look smaller (“we have to wait for legal — that’s just how it works”). The discipline is to keep the speed-of-light number ruthlessly physical and put everything else in the gap column.
Using it inside TBD
A few places it maps cleanly to where we are in RDI Phase 3:
- Interview-to-insight loop. Speed of light: interview ends → transcript ingested → scrap pile updated → next interview booked. What’s the minimum if every step ran the moment the prior one finished? Where’s the gap? Usually scheduling and review. Fine, but worth seeing.
- Customer commit. From “I want to talk” to a signed pilot, what is the physical minimum number of working hours? Compare to actual.
- Product spin-up. When we start a digital twin for a new firm, what’s the physical minimum given only data ingestion plus the queries we’d actually run? Compare to first-version pace.
Don’t apply it everywhere. That’s exhausting. Apply it to the two or three loops that define how fast we learn and how fast we ship.
Using it in NVIDIA conversations
Three concrete plays for our upcoming meetings:
- Speak the language. When NVIDIA asks for a timeline, give the speed-of-light number first and then the realistic plan. They’ll recognize the move and respect it. Don’t fake the speed-of-light number; they’ll spot it.
- Frame our wedge as a speed-of-light argument. Parametric insurance and futures collapse the time between “disruption happens” and “balance sheet is whole again.” That’s a speed-of-light claim about working capital, not a risk-management claim. It’s the kind of framing they reward. See financialization primer for the underlying mechanics.
- Don’t oversell. Jensen’s culture is allergic to slogans without substance. Use the concept where it actually fits. Don’t sprinkle it.
Bottom line: speed of light replaces “are we ahead of the field?” with “are we close to physics?” The first question lets you coast. The second one is a forcing function. For a two-person founding team in a slow-moving industry, that’s exactly the right forcing function to install early.
Sources: The Thinking Machine (Stephen Witt, 2025); NVIDIA shareholder letters; Jensen’s public talks. Concept synthesis, not direct quotes.