Larry Page

The pattern they actually represent

Google's April 2004 prospectus described the machinery in a sentence most companies would have buried. The business ran "a large network of commodity computers running custom software developed in-house". Read what the same filing lists as the benefit. Not speed. Not elegance. It "eases the deployment and operation of large-scale global products and services and automates much of the administration of large-scale clusters of computers".

The default then was to buy reliability — branded rack-mount servers, bigger machines, a vendor's warranty. The disclosed choice was the inverse. Buy the cheapest unreliable units, hold the whole thing together in software, and adding capacity becomes a purchasing decision instead of a re-engineering project. That architecture was sized for a web much larger than the one being served in 2004, and the company told its incoming shareholders so.

The same filing carried the founders' letter, which makes the identical refusal in plain English. Google "is not a conventional company", it would not smooth its quarters, and a management team distracted by a series of short term targets is, in the letter's words, as pointless as a dieter stepping on a scale every half hour. It also names the failure mode out loud. Most people naturally gravitate toward incremental improvements.

Eleven years later Page opened "G is for Google" by quoting that 2004 sentence back, said companies get comfortable making incremental changes, and then rebuilt the org chart around it. Alphabet moved the speculative businesses out from under Google, each with its own leader and its own accountability.

The eleven-year gap is the evidence. The ambition was not a mood. It went into a prospectus, then into an architecture, then into a corporate structure — each time before the thing it was sized for arrived.

The blockage it speaks to

Read this one if your week is mostly tuning.

You shaved another two hundred milliseconds off a page that gets a few hundred visits. You refactored the internal tool you open twice a week. You rewrote the onboarding sequence for the fourth time. All real work, and all of it made a system that already works fine at today's volume work slightly better at today's volume.

Meanwhile the decision that would matter at ten times the size sits unmade. The manual step one person does by hand every morning. The single table everything hangs off. The price you would have to change if the traffic tripled.

Tuning wins because tuning pays out today. You can watch the number move by Friday. A structural decision pays out on a schedule you cannot see from here, costs real money now, and for a long stretch anybody can call it waste. So what to build for gets postponed into what to measure. You will size it properly once you know the volume, and knowing the volume needs the system you have not built.

Page is the right study here, and not because he thought big. He is the study because the sizing decision got made once, early, on purpose, and then defended in public while it still looked unnecessary.

Three moves you can steal

Write down the load you are building for. One number, eighteen months out — customers, requests, orders, students, whatever your system counts. Then walk your current setup against that number and name the first three things that break. Most of what is on your week will not be on that list. The number turns "should I be improving this?" from a matter of taste into a matter of arithmetic.

Choose the option you can grow with a purchase, not a rewrite. The prospectus does not claim the hardware was good. It claims the infrastructure eased deployment and operation and automated administration at scale — the boring properties, the ones that decide whether growth arrives as a bill or as a project. When you pick a tool, a schema or a process, ask what happens at ten times the volume. Does somebody pay more, or does somebody rebuild it?

Put in writing the thing you are not going to improve this quarter. The founders' letter is a precommitment made in a document you cannot quietly edit afterwards. Yours can be four lines your team reads. Naming the tuning you are refusing does something an intention never does. It makes the reflex visible at the moment you reach for it.

Where the pattern breaks

From May 2007 to May 2010 the Street View fleet logged Wi-Fi network identification data for a geolocation database, and also logged payload data — the contents of communications on unencrypted networks — which that database never needed. On 12 March 2013, a coalition of state attorneys general settled for $7 million, with remedies including destroying the payload data collected in the United States. The separate $25,000 FCC forfeiture of 13 April 2012 was not for the collection. The Enforcement Bureau declined to pursue that, and fined the company for failing to answer its letter of inquiry. A fleet built to map the planet swept up more than the map needed. Decide what a system may collect before it reaches the size you are building for.

What to do this week

Write the number. One line, eighteen months out, the volume you actually expect and not the one that would be nice. Then take an hour with your current setup and list what breaks first at that number — the manual step, the table, the person, the price.

Pick the cheapest item on that list and make the structural version of the decision this week, not the tuned one. Move the schema now, while there are four hundred rows in it. Buy the boring thing you can add more of later.

Then write one sentence naming what you are not going to improve until that number arrives, and put it where your team will see it. The tuning will still be there in eighteen months. The window to choose the shape is open now.