·Business & Strategy
Section 1
The Core Idea
A forcing function is a constraint deliberately introduced to compel a desired behaviour or outcome. It works by eliminating alternatives, compressing timelines, or restructuring incentives so that the path of least resistance becomes the path you actually want people to take. The defining feature: the constraint is not accidental. Someone chose it.
The concept is ancient. In 1519, Hernán Cortés landed on the coast of Mexico near present-day Veracruz with roughly 600 soldiers, a force absurdly outnumbered by the Aztec Empire. He ordered his ships scuttled — hulls stripped, vessels sunk or beached beyond repair. The act eliminated retreat as an option. Every soldier understood the arithmetic: march inland and conquer, or die on a foreign shore. The constraint didn't make success more likely in any probabilistic sense. It made full commitment the only rational response. Cortés reached Tenochtitlan by November 1519 with his force intact.
Julius Caesar executed the same logic twenty centuries earlier. On January 10, 49 BCE, Caesar marched the Thirteenth Legion across the Rubicon river — a shallow stream in northern Italy that served as the legal boundary beyond which no Roman general could bring armed troops. Crossing it was treason against the Roman Senate. There was no walking it back. Caesar reportedly said
"alea iacta est" — the die is cast. The crossing converted an ambiguous political situation into a binary one: total victory or total destruction. Within sixty days, Caesar controlled Rome. The forcing function didn't guarantee success. It guaranteed commitment — and commitment, applied with speed, overwhelmed an opponent that was still debating.
The modern application looks different but follows identical logic. C. Northcote Parkinson observed in a 1955 essay for
The Economist that "work expands so as to fill the time available for its completion." The insight — now called
Parkinson's Law — is a description of what happens in the
absence of a forcing function. Give a team six months and they'll use six months. Give them six weeks and they'll compress, prioritise, and cut scope to deliver something. The deadline doesn't change the team's ability. It changes their behaviour. It forces triage — the ruthless separation of essential from optional — that humans are psychologically terrible at performing voluntarily.
Jeff Bezos built forcing functions into Amazon's operating system at the structural level. The "working backwards" press release — a practice documented in Colin Bryar and Bill Carr's 2021 book
Working Backwards — requires product teams to write a mock press release and FAQ for their product before a single line of code exists. The press release must articulate, in plain language, what the product does, who it serves, and why it matters. Teams that can't write a compelling one-page announcement for their idea don't get to build it. The document is a forcing function for clarity: it eliminates the option of starting with vague ambitions and hoping the vision crystallises during development. When AWS was conceived internally in 2003, the working-backwards document exposed that the service's success depended entirely on whether external developers would trust Amazon with their infrastructure — a dependency that shaped every subsequent product and pricing decision.
Bezos also imposed the two-pizza team rule: no team should be so large that it can't be fed by two pizzas. The constraint — roughly six to ten people — wasn't about food. It was a forcing function for organisational design. Small teams can't hide behind coordination overhead. They can't diffuse responsibility across fifteen people. Every member is visible. Decisions happen faster because the communication paths are fewer — in a ten-person team, there are 45 possible person-to-person communication channels; in a twenty-person team, there are 190. The constraint forced Amazon's engineering culture toward autonomous, high-velocity units at a scale where most organisations drift toward bureaucratic committee structures.
Steve Jobs applied forcing functions to entire industries. In 1998, when Apple introduced the iMac, Jobs made the controversial decision to eliminate the floppy disk drive — a component that had been standard on personal computers for nearly two decades. The decision was widely criticised.
PC Magazine called it "a different kind of gamble." But the removal forced both Apple's engineers and the broader industry to adopt USB and internet-based file distribution years ahead of what incremental evolution would have produced. The constraint didn't create USB — Intel and Compaq had published the USB standard in 1996. It forced adoption by removing the fallback.
The structural insight: a forcing function converts a continuous problem (how much effort should we apply?) into a binary one (do the thing or don't). Binary problems are psychologically simpler and produce faster action. Continuous problems invite optimisation, deliberation, and the comfortable middle — the 60% effort, the half-measure, the "let's revisit next quarter." A well-designed forcing function eliminates the middle entirely.
Elon Musk deploys forcing functions through a different mechanism: impossible deadlines. When SpaceX was developing the Falcon 1, Musk set an eighteen-month target for first launch — the industry standard was five to seven years. SpaceX missed the target by three years. Tesla's Model 3 production target of 5,000 vehicles per week by end of 2017 wasn't hit until July 2018. The deadlines are almost never met on schedule. That's not the point. The point is that a deadline so aggressive it can't be achieved through conventional methods forces the team to abandon conventional methods entirely. Engineers at SpaceX built components in-house rather than waiting for vendors. Tesla restructured its entire assembly line mid-production. Whether the deadline is met or missed, the behaviour it produces — radical compression of decision cycles, elimination of bureaucratic process, willingness to try approaches that "reasonable" timelines would never justify — is the output the forcing function was designed to create.
The pattern across all these cases is identical: the forcing function works not by adding capability but by removing optionality. Cortés didn't give his soldiers better weapons. Caesar didn't hire more legions. Bezos didn't give product teams more resources. Jobs didn't build a better floppy drive. Musk didn't give engineers more time. They each removed the comfortable alternative — retreat, ambiguity, bloated teams, legacy technology, conventional timelines — and let the constraint do the work that willpower alone could not.
