Summer 1995. Paul Graham, thirty-one, with a Harvard computer science PhD, was stuck in a pattern: take consulting work he hated, save enough money to quit and paint for a while, run out of money, repeat. A radio segment promoting Netscape's upcoming IPO — vague, hyped, promising limitless online commerce — caught his attention at exactly the moment he was tired enough of the cycle to want something different.1
He called his old programming partner Robert Morris. Neither had a clear idea of what to build. What they had was a shared preference: write software that could generate an online store for a business, and do it in Lisp on Unix — because they were committed hackers who despised Windows and had never bothered learning to develop for it.2
Writing for Unix first, planning to port to Windows later, ran into an obvious wall: any real success would eventually force them into months or years of Windows development anyway, dealing with users and feedback in an environment they actively hated. Faced with that prospect, they nearly abandoned the whole idea.3
The solution arrived from Graham half-asleep, on a mattress on Morris's floor: he woke up repeating words that seemed to have surfaced from a dream — "you could control the program by clicking on links." The realization that followed was immediate: build the store-creation software to run on the web server itself, accessed and operated entirely through a browser. No desktop download, no Windows development, ever.4 Within days, a working version existed.
What started as an aversion to Windows produced, once built, a cascade of benefits nobody had designed in deliberately. Running entirely on the web meant continuous software releases tested immediately, rather than the months-long cycles standard for desktop software. Direct contact with merchants — Graham and Morris did their own sales calls, having no idea a company was supposed to hire salespeople for that — meant they personally heard every complaint and suggestion first-hand. And because the whole approach was strange enough that nobody else had attempted it, they had no real competitors for a meaningful stretch of time.5
Several genuine mistakes happened along the way. None of them mattered enough to sink an idea Graham later described as simply too strong to fail. In 1998, Yahoo! bought the company, Viaweb, for $50 million.
Graham's next major move shows the same underlying mechanism operating a second time, more deliberately. After Viaweb, he started writing essays online, gained a following among young programmers, and was eventually invited to speak to Harvard computer science undergraduates — where the audience's questions about their own startup ideas revealed real, if unrefined, potential.6
Wanting to try angel investing but having no relevant track record, Graham made an initially odd-sounding decision: rather than invest cautiously in one or two startups the way established investors typically start, he'd fund ten at once, all together, treating the batch explicitly as his own crash course in the investing business as much as a bet on the founders.7 A few weeks in, he and Morris realized the training-wheel structure they'd built for themselves was actually a powerful method in its own right — and scaling it up became Y Combinator, eventually valued at $500 million.8
Greene reaches outside human creativity entirely for the mechanism's proper name, borrowing it from evolutionary biology: feathers evolved on reptiles for warmth, and only later got hijacked by their bird descendants for flight. The primate hand evolved for gripping branches, and got hijacked by ground-walking hominid descendants for tool use and gesture. Even language, on this account, may have started as a purely social bonding tool before getting hijacked as a vehicle for abstract reasoning.9
Human creativity, in Greene's reading, runs on the identical structure far more often than the tidy, linear "had an idea, refined it" story usually told about invention. Something gets built or adopted for one reason — Unix and Lisp, chosen out of simple aversion to Windows — and then, by accident and contingency rather than foresight, gets repurposed for something the original choice never anticipated.10
The mechanism sounds passive — waiting for a lucky repurposing to fall into your lap — but Greene's point is closer to the opposite: hijacking depends entirely on a specific kind of openness and flexibility that lets the repurposing actually get noticed and followed once contingency offers it. Someone locked into their original plan, treating the Unix-versus-Windows aversion as a fixed obstacle rather than a live constraint worth reasoning through creatively, never reaches the browser-based insight at all.11 The creative act isn't generating the accident. It's staying loose enough to actually see and follow where the accident points.
Greene's closing image reframes the shape of the whole creative process this case illustrates: not a straight line from idea to finished execution, but something closer to a tree's crooked branching — one choice opening unplanned options, each of those opening further ones, with the actual final shape only visible looking backward.12 Graham didn't plan Viaweb's architecture, then Y Combinator's structure, as two steps in a single foreseen sequence. Each grew out of contingencies the previous stage happened to expose, followed rather than engineered.
You're stuck on a technical or practical obstacle and the obvious path forward requires doing something you find genuinely unpleasant. Before forcing yourself through it, spend real time asking whether the aversion itself is pointing toward a different, better-fitting solution — Graham's Windows aversion generated Viaweb's entire architecture.
Something you built for one specific, narrow reason is producing unexpected side benefits you didn't plan for. Don't dismiss them as incidental. Follow them seriously — Viaweb's rapid-release cycle and direct customer contact were accidents of the web-server architecture, not features anyone designed in from the start.
You're trying something new without relevant prior experience and feel like an impostor. Consider reframing the attempt itself, the way Graham did with his first ten investments, as a deliberate crash course rather than a premature bid at expertise you don't yet have.
Graham's Viaweb and Y Combinator origin stories are well documented, largely through Graham's own widely read essays, and Greene's account tracks that record closely — though it relies heavily on Graham's own retrospective narrative rather than independent verification.
Open question: the evolutionary-hijack framing, borrowed from biology, describes a process with no intentionality behind it — a mutation simply persists or doesn't, with no organism "noticing" the opportunity. Applied to human creativity, Greene quietly reintroduces the very intentionality the biological metaphor excludes (a person has to notice and choose to follow the accidental opening). The metaphor illuminates the accidental origin but obscures the deliberate follow-through, and Greene doesn't flag the mismatch.
This page converges directly with Allow for Serendipity, built earlier in this same chapter — both describe valuable outcomes arriving through chance rather than planned pursuit. The distinction worth holding onto: serendipity describes chance encountering a prepared mind mid-search; evolutionary hijacking describes something already built for one purpose getting repurposed for an entirely different one later. Graham's case actually contains both — the dream-image of clicking links was serendipitous; the years-later realization that Unix-and-Lisp aversion had produced an entire scalable business model was hijacking.
Advance Through Trial and Error — Graham's own earlier "hacker model," documented on this vault's Cluster C page from his apprenticeship material, treats iterative, low-commitment experimentation as a standing creative discipline. The insight the pairing produces: evolutionary hijacking isn't a one-off lucky break in Graham's biography, it's the predictable output of a working method he'd already built for himself years earlier — the hacker model generates enough loosely-committed experiments that some of them are statistically likely to get hijacked into something unplanned, which means the "luck" in this case study is closer to a manufactured surplus of raw material than to pure chance.
Unintended Consequences — this Laws of Human Nature page catalogues cases where good intentions produce outcomes nobody planned, treating unintended consequence as a risk factor to actively guard against. Evolutionary hijacking describes the identical structural phenomenon — an action producing effects beyond its original purpose — reframed as an opportunity to actively watch for rather than a danger to defend against. The insight the pairing produces: unintended consequences aren't inherently negative or positive, they're simply what happens whenever a system (a policy, a piece of software, a body part) gets deployed into a context wider than the one it was designed for — and whether that's read as risk or opportunity depends entirely on whether the consequence is noticed and can be steered, not on anything intrinsic to the mechanism itself.
Sharpest implication. If the most consequential creative outcomes in this case arrived through aversion and accident rather than foresight, then a strategic planning process built entirely around deliberate goal-setting may be structurally worse at producing genuine innovation than a looser process that simply generates a lot of small, honestly-motivated choices and stays alert for which ones get unexpectedly hijacked.
Generative questions.