The answer lives in this podcast

Answer extracted from The Conference Room with Simon Lader podcast — listen to the full episode below.

🎧 Listen to the episode on Listenly

How do large organizations like Amazon and AWS maintain innovation despite their enormous scale?

September 22, 2026 The Conference Room with Simon Lader · David Etchew

← See The Conference Room with Simon Lader fiche

Large organizations stay innovative by applying the two-pizza rule—keeping teams small enough to feed with two pizzas (under 12 people), a principle AWS used to launch S3 and transform cloud storage. Success also depends on writing the press release before building the product, granting autonomy between functions, and avoiding dependencies that slow decision-making.

Scale typically stifles innovation because bureaucracy, approval chains, and interdependencies slow execution. Yet companies like Amazon and AWS have cracked a different code: they treat innovation as a structural problem, not a cultural one. Etchew observed this firsthand while working with these organizations on encryption and cloud technologies.

The two-pizza rule emerged as a core organizing principle inside AWS. As explained in the episode, when AWS launched S3—arguably the foundational service that enabled modern cloud computing—they did it with only 12 people on the core team. That constraint forced clarity: what's essential, and what isn't? Small teams make faster decisions, own accountability completely, and sidestep the lengthy consensus-building that hamstrings larger groups.

Writing the press release before building the product

Another counterintuitive practice Etchew highlighted is beginning with the customer perspective. Instead of building first and writing marketing copy second, teams write the press release—the public-facing narrative of what the customer will experience—before a single line of code is written.

This disciplines the entire effort around what actually matters to the user, not what's easiest to build internally. It forces honest conversations: Is this feature worth building? Does it solve the problem we claim it solves? A product built backward from the customer promise is less likely to be a technical achievement that nobody wants.

The practice also acts as a forcing function for simplicity. A press release cannot dance around complexity or hide behind jargon—if you can't explain the value clearly in a paragraph, you haven't understood it yet.

Autonomy and minimal dependencies

At the organizational level, large companies often suffer from function-to-function dependencies that create chokepoints. One team needs approval from another, which needs input from a third, and the whole system grinds to a halt. AWS broke this by granting genuine autonomy between teams and business units, minimizing the need for cross-team coordination on every decision.

This doesn't mean chaos. It means each team owns its domain fully—including its failures. A team can choose its technology stack, decide its roadmap, and ship without waiting for central alignment, as long as they respect the contract they made with the customer (the press release) and don't break upstream services.

"I could fail every day as long as I failed differently the day before I learned from it. The thing that drives me nuts is failing the same way twice."

This philosophy underscores why large organizations don't have to sacrifice speed. The constraint isn't size—it's structure. The episode goes deeper into how teams navigate failure and learning, showing that even inside organizations with thousands of employees, individual teams operate more like startups than departments.

These principles—small team size, customer-first thinking, and functional autonomy—apply regardless of company scale. A five-person startup and a 50,000-person corporation can both benefit from the two-pizza rule if they respect the discipline it demands. Etchew shares concrete examples of how these practices play out in practice, including the tension between scaling and staying nimble.

See also