How Google Works

1. 1Protect a fixed slice of unstructured time — 20 percent time — and defend it against managers who deny it; the concept only survives if leaders treat manager refusal as the exception, not the norm. When you learn a manager blocked a performer's side project, investigate and correct, as the authors did with the New York engineer.
2. 2Structure resource allocation on the 70/20/10 pattern: put the bulk into your core business, a meaningful minority into adjacent efforts, and a protected slice into speculative bets so ideas have somewhere to grow.
3. 3Set almost-unattainable 10X goals rather than incremental ones. Force teams to reason from first principles and real-world physics ('what's actually possible') instead of accepting prevailing wisdom, because incrementalism leads to irrelevance over time.
4. 4Fund bets by future potential market value, not this fiscal year's revenue. Reject the classic MBA move of ranking projects by IRR/NPV and doling out cash until it runs out; budget as an investment in growing the business.
5. 5Ship and iterate: launch a first version (Ingress before Pokémon Go), let it be a moderate success, then use what you learn to pave the way for the bigger product.
6. 6Let ideas come from anywhere and keep the business outrunning its processes, so chaos remains 'right where you want to be' — dependence on process squelches the start-up spirit.
7. 7Institutionalize failing well: give strong leaders the means to build a start-up inside the company with the real freedom to succeed or fail on their own, and treat productive failures as the cost of ambition.

John Hanke wanted to build an augmented-reality gaming platform using mobile phones and Google's maps, and decided to leave Google to start it. When he told Larry Page, Larry's surprising response was that John should build it inside Google. They gave his venture, Niantic Labs, a separate compensation structure, independent decision-making, and freedom to set its own hiring, offices, and streamlined launch process — 'about as close to a start-up environment as could be achieved within a big company.' Niantic shipped Field Trip, then in 2012 the multiplayer game Ingress, a moderate success that 'paved the way' for Pokémon Go, the 2016 craze made with the Pokémon Company and Nintendo. Niantic spun out of Google in September 2015 as an independent company. John got to pursue his idea and see it succeed; Google learned that giving a strong leader a start-up within the company was feasible and productive. This is the whole ooze thesis in one arc: freedom, ship-and-iterate, and organic evolution from a modest launch to a breakout.

• If a strong leader has an itch to start something new and is about to leave, then offer to let them build it inside the company with real autonomy rather than lose them.
• If a manager refuses a performer's 20 percent project, then treat it as an exception to investigate and correct, not a policy to accept.
• If you're budgeting a growth venture, then size the investment by the ultimate market value years out, not by this year's revenue.
• If a goal feels merely ambitious, then push it toward 10X so the team reasons from physics rather than assuming impossibility.
• If the business is comfortably keeping pace with its processes, then you're not going fast enough — force chaos back in.

• Letting the company become slower and more process-driven as it grows — the tell is Googlers saying 'maybe you should have called it How Google Worked.'
• Allowing promotion and budget processes to punish the innovative unit: engineers avoided YouTube because promotion was harder there, and the smaller unit got starved by revenue-based budgeting.
• Budgeting by cost of capital, hurdle rates, and IRR/NPV rankings until cash runs out — optimizes efficiency and kills investment in the future business.
• Requiring every i dotted and t crossed before you act — the tell is waiting for a full FAQ of well-scripted answers when boldness demands moving with details still unresolved.
• Defaulting to incrementalism because moonshot thinking feels impossible — the tell is teams assuming things can't be done rather than starting from real-world physics.

• ▸Idea / bet name: what you're giving room to evolve
• ▸20% protection: how the side-project time is guaranteed and who could block it
• ▸70/20/10 split: percentages to core, adjacent, speculative
• ▸10X goal: the almost-unattainable target stated in first-principles terms
• ▸Investment basis: future market value estimate driving the budget (not this year's revenue)
• ▸First shippable version: the smallest thing you can launch and iterate from
• ▸Iteration signal: the moderate-success metric that would justify the bigger swing
• ▸Autonomy grant: hiring, comp, offices, and launch process this team controls
• ▸Fail-well terms: how success or failure is judged and what a productive failure earns

1. 1Treat hiring as your highest-leverage work, then run the herd effect: hire one exceptional smart creative and use them to attract more, because the best people flock to organizations where they sense a good fit (Schneider's attraction-selection-attrition model).
2. 2Build the crowded, live-together-and-work-together environment where smart creatives can succeed at scale—the environment, not the perk, is the retention mechanism. In a big company, actively fight the process forces that drop rocks on people trying to do something different.
3. 3Set almost-unattainable goals via OKRs: marry a big-picture objective to a highly measurable key result, aim for difficulty where full marks are rare, and use 'think big' as a recruiting and retention tool because it is contagious across sales, legal, and finance too.
4. 4Protect challenge for your best people: when managers rotate staff off teams, make them trade away their 'M&Ms' (top performers) and keep the 'raisins,' so stars stay challenged rather than hoarded on one team.
5. 5Give audacious builders room—up to spinning out ventures or organizing around CEO-type smart creatives who need freedom from cumbersome process and cross-team politics.
6. 6When a star signals leaving, focus retention on stars, leaders, and innovators; start by listening, because people seldom leave over compensation—they want to be heard, relevant, and valued.
7. 7In the retention conversation, act as advocate for the departing smart creative, not the organization; help them take a longer-term view and find a way to recharge while staying.
8. 8Default to open on OKRs, board letters, and product roadmaps so people can quickly find what motivates each other—transparency reinforces the culture that attracts and holds this talent.

Mike Cassidy, an aerospace engineer, was a Loon project lead who had been working on high-bandwidth balloon connectivity for over a year. The authors state plainly that if it weren't for the opportunity to do something audacious, he likely would have left Google. By continuing to think big and push technology boundaries, the company retained at least one great smart creative. The effect extended beyond Mike: people across Google—salespeople, lawyers, financial folks far removed from the moonshots—talk about '10Xing' their jobs, inspired by the prevalent shoot-for-the-moon attitude. This shows the retention mechanism at work: the meaningful challenge held the specialist directly, and the herd/contagion effect held everyone watching. Thinking big functioned as both recruiting tool and retention tool.

• If a manager wants to hold their top performer on one team, then make them trade the star away and keep the average performer, because hoarding leaves your best people un-challenged.
• If a star, leader, or innovator signals they're leaving, then do whatever it takes to keep them—their exit ripples and inspires their followers to leave too.
• If you're in a retention conversation, then be the advocate of the smart creative, not the organization; skip 'Please stay!' and listen to why they want to leave.
• If a builder has the audacity and talent to start a new venture but chafes at big-company process, then give them freedom to build their way—up to a start-up-within-the-company or spin-out.
• If a goal produces a perfect 100 percent scorecard easily, then it was set too low; a good OKR should look difficult and rarely earn full marks.

• Letting process conspire against smart creatives—the engineer whose manager forbade 20 percent projects is the tell; a well-performing person with ideas gets blocked and starts calling it 'How Google Worked.'
• Setting underpromise-and-overdeliver goals so you can 'miraculously' exceed them; the tell is a scorecard full of easy 100 percents and no ambitious misses.
• Treating retention as a compensation problem; the tell is offering money first when the person actually wanted to be heard and feel relevant.
• Trying to force CEO-type builders into cumbersome corporate structure—the tell is a safety officer carting perfectly good salt out of a lab because it 'expired,' little things blocking big ideas.
• Managers hoarding top talent on their own teams; the tell is the Halloween-candy instinct to keep the Reese's and shed the raisins, which locks up your best people.

• ▸Herd anchor: which exceptional hire will draw the next tier of talent?
• ▸Environment audit: what process forces are dropping rocks on your smart creatives?
• ▸Meaningful challenge: what audacious, almost-unattainable OKR is assigned to each key person?
• ▸Objective + key result: state one big-picture goal married to one measurable result.
• ▸M&M ledger: which stars are hoarded on one team and where should they rotate?
• ▸At-risk stars: name the leaders/innovators whose exit would ripple.
• ▸Retention listen-log: what did each at-risk person actually say about why they'd leave?
• ▸Recharge path: how can they take a longer view or recharge while staying?
• ▸Open-by-default items: which OKRs/roadmaps/board notes are shared company-wide?

1. 1Hire for intellect first, then grant freedom: Larry and Sergey's operating rule was to hire the best software engineers and give them room, using communication—not dictation—to keep everyone pointed the same way. Replicate this by defining direction and constraints, not tasks.
2. 2Institutionalize self-directed time. Google formalized 20 percent projects as a standing right, not a manager's gift. State explicitly that this freedom is a company-level entitlement so no single manager can revoke it.
3. 3Signal that status is not measured in square feet. Eric took a closet office rather than displacing engineers; Amit moved into Eric's office. Remove the physical and hierarchical cues that tell people to defer, so they take initiative on their own volition.
4. 4Match challenge to skill to produce flow. Csikszentmihalyi's flow requires an ideal match between a highly challenging task and the person's ability—too hard breeds anxiety, too easy breeds boredom. Actively size assignments to sit at the edge of each person's capability.
5. 5Offer big responsibility and skill-stretch, not just perks. Per Kanter, knowledge workers stick where they can take on big responsibility, use the best tools for the best customers, and build human capital. Make current work a visible promise of greater future responsibility.
6. 6When someone has the audacity to build an entire new venture, give them a structural carve-out. Google gave John Hanke's Niantic a separate compensation structure, independent decision-making, its own hiring and offices, and a streamlined launch process—a start-up inside the company.
7. 7Define culture by asking the trusted core team what they care about and believe, then write it down—and make sure employees actually believe the words, because that belief is what separates successful companies from unsuccessful ones.

John Hanke wanted to build products his own way inside Google, so leadership gave Niantic Labs a genuine start-up environment: a separate compensation structure, independent decision-making, its own hiring practices and offices, the freedom to work unfettered across Google product teams (what John calls 'breaking walls'), and a much more streamlined launch process. It was hard to set up, but once the details were worked out, the team ran on its own volition. Niantic shipped Field Trip, then the multiplayer game Ingress in 2012—a moderate success that paved the way for Pokémon Go in 2016. Niantic spun out as an independent company in September 2015. John got to pursue his idea and see it succeed; Google confirmed that giving a strong leader the means to build a start-up inside a big company was feasible and productive. The empowerment was real because it came with structural autonomy, not just encouragement.

• If the task is highly challenging but the person's skill is low, then expect anxiety—scaffold or resize it; if the task is no match for their ability, then expect boredom—raise the challenge.
• If a manager unilaterally blocks a standing freedom (like 20 percent projects), then treat it as a policy violation, not a manager's discretion, because the freedom is a company-level tradition.
• If someone has the audacity and talent to start an entire new business, then give them a structural carve-out rather than forcing them through cumbersome processes and cross-team politics.
• If you're documenting culture, then ask the founding/core team what they believe before anyone in HR or PR drafts a statement—otherwise the words won't be believed.
• If empowerment is only messaging and not how you actually run the company, then it will fail; run it the way Larry and Sergey did—actually meaning it, not as corporate messaging or altruism.

• Delegating culture-writing to someone outside the founding team, producing 'delighted customers' and 'maximized shareholder value' boilerplate that employees don't believe. Tell: the mission statement reads like generic corporate sayings.
• Granting freedom on paper but letting individual managers quietly revoke it—the New York engineer whose manager refused to allow 20 percent projects. Tell: the stated philosophy and the lived experience diverge team by team.
• Measuring importance in square feet and hierarchy, which trains people to defer instead of act. Tell: leaders guard offices and status symbols instead of decamping to closets.
• Mismatching challenge and skill so people sit in boredom or anxiety instead of flow. Tell: high performers disengage or churn despite good pay.
• Offering only perks instead of real responsibility and skill growth. Tell: retention drops because people can't build their human capital or see a path to greater future responsibility.

• ▸Person/Team & their highest-impact strength: name who you're empowering and why.
• ▸Direction & constraints (not tasks): the general direction they must move toward.
• ▸Standing freedoms guaranteed: e.g., self-directed time protected at company level, not manager discretion.
• ▸Challenge-to-skill check: is this task at the edge of their ability (flow) or too easy/hard?
• ▸Structural carve-outs (if a new venture): separate comp, independent decisions, own hiring/offices, streamlined launch.
• ▸Human-capital promise: what bigger responsibility/skills this builds for their future.
• ▸Status-signal removal: which hierarchy/office cues you'll eliminate so they act on their own volition.
• ▸Belief test: do the people affected actually believe the stated freedom is real?
• ▸Review trigger: what would signal the granted freedom is being quietly revoked?

1. 1Start from a technical insight, not a business plan: identify one or more technologies applied in a new way to solve a big problem. When you evaluate whether an idea deserves a team, look first for that insight — the business model and financials are necessary but secondary.
2. 2Build the smallest prototype that tests the insight, then expose it for reuse. Wrap your capability in an interface others can access (an API, a demo, a shared tool) so adjacent teams can find it and build on it without asking permission.
3. 3Recruit first followers by making the idea easy to seize. Publicize what you built to teams whose metrics your capability could move; let engineers who see the fit implement the change themselves and measure the impact.
4. 4Work across walls: collaborate freely across product teams and hierarchies, judging ideas on merit not provenance. Take action on your own initiative rather than waiting to be told, and speak up when you disagree.
5. 5De-risk the product first, then de-risk the business. Prove the product works and matches the vision, prove the business model is commercially viable, and only after both are proven look to scale.
6. 6Set aggressive milestones and timelines that make failure fast and cheap. Expect a large fraction of attempts to fail early; treat 'failing to fail' — surviving the kill criteria — as the signal to continue.
7. 7Give proven leaders air cover to focus on the product by removing the political, time-consuming distractions (office space, safety paperwork, PR docs) so they can spend all their time de-risking product and business.

A Google engineer, Jim McFadden, was working out how to observe anonymized user behavior and run linear regression on it at massive scale (insight #1). Rather than keep it inside his research team, he realized other teams might want it and built an API so any program could access his system. YouTube engineers heard about it and seized on it as a way to improve which video to recommend next; they implemented the change themselves and video views went up dramatically. Then Cristos Goodrow, an engineering director who had just moved over from the commerce group, brought a second insight: the real currency at YouTube wasn't views but watch time — the point is getting people to watch, not click (insight #2). He convinced Salar and the rest of the YouTube leadership. The chain worked because a capability was made reusable, another team acted on their own initiative to apply it, and a cross-functional hire imported an insight from a different discipline.

• If an idea rests on a genuine technical insight (technologies applied in a new way to a big problem), then back it with a team; if it's only a business strategy or financial model, then hold off.
• If the product isn't yet proven to work and match the vision, then do not scale — de-risk product and business before everything else.
• If a proven leader with an itch to start something wants freedom, then give them a start-up-like structure inside the org (independent decisions, own hiring, streamlined launch) rather than forcing them through cumbersome process.
• If a capability you built could help another team's metric, then expose it (API, demo) and let them implement it themselves rather than hoarding it.
• If you judge an idea by who proposed it rather than its merits, then stop — evaluate ideas on merit and provenance-blind.

• Waiting for direction or permission before acting — the tell: the idea sits in your head or a conference room while you 'think about it even when you should be doing something else' but never prototype or recruit a follower.
• Optimizing the wrong metric because you never questioned it — the tell: like measuring views instead of watch time, you keep hitting a number that doesn't equal real value.
• Scaling before de-risking — the tell: you're building offices, hiring, and marketing while the core product still hasn't been proven to work.
• Letting big-company forces drop rocks on the initiative — the tell: leaders get pulled into office-space logistics, expired-salt safety sweeps, or peripheral PR Q&A documents instead of the actual product work.
• Hoarding data, tools, or computing power — the tell: your capability stays locked in your team with no interface, so adjacent teams never discover it and the reuse never happens.

• ▸Technical insight: the one or more technologies applied in a new way to solve a big problem
• ▸Reusable hook: how you'll expose the capability (API, demo, shared tool) so other teams can seize it
• ▸First followers: which teams whose metrics this could move, and who will you show it to
• ▸Walls to break: which product teams / functions you must collaborate across, and the point of contact
• ▸Real metric check: is the number you're optimizing the true currency (e.g., views vs. time)?
• ▸Product de-risk test: the smallest experiment proving it works and matches the vision
• ▸Business de-risk test: the check proving the model is commercially viable
• ▸Kill criteria & timeline: the aggressive milestone and date by which you fail fast or continue
• ▸Air cover needed: which distractions (space, admin, PR) someone must remove so you focus on product

1. 1Name the three converging trends that define your context: free/ubiquitous information, continuous mobile connectivity, and near-infinite cheap cloud computing. Write down which of the three most changes your industry's economics.
2. 2Recalculate your cost of experimentation. Because prototyping, market testing, and fundraising can now happen online with tools like 3-D printers and slick videos, budget for many cheap iterations rather than a few expensive bets.
3. 3Audit your existing management process against these economics. Identify any command-and-control gate, roadmap, or approval chain built for a century-old world where mistakes were expensive and only executives held information — those slow you down precisely when you must accelerate.
4. 4Make product excellence and speed your primary metric. Replace 'lower risk / few informed deciders' objectives with 'ship, get data, iterate faster than the change rate.'
5. 5Start Eric's conversation regularly: ask 'What's different now?' Something is always different; use the answer to spot when your assumptions have gone stale and change has become revolutionary rather than incremental.
6. 6Combine the moonshot (10X) and roofshot (1.3–2X) modes so speed compounds — chase big bets while running relentless continuous improvement, since both benefit from cheap experimentation.
7. 7Empower small teams and individuals to act on abundant data instead of hoarding it, because information-based work now lets tiny teams have outsized impact.

Google[x] built the first prototype of Google Glass, a wearable computer as light as sunglasses, in just ninety minutes. It was crude, but that was the point — 'Don't tell me, show me.' In the Internet Century, radically better products don't stand on the shoulders of giants; they stand on the shoulders of lots of iterations. The ninety-minute build worked because prototyping had become cheap and fast, letting the team test a real object rather than argue over a spec. The same economics let anyone with a 3-D printer make prototypes, market-test them online, adjust the design from the resulting data, and even raise production funds with a video. Speed, not a perfect first plan, is the basis for continual product excellence.

• If change in your field is revolutionary rather than evolutionary, then place big bets on the future instead of making incremental improvements — incrementalism leads to irrelevance in technology.
• If an experiment is cheap and failure (done well) is low-cost, then run it rather than debating it upward through executives.
• If your management architecture slows decisions down (data flows up, decisions flow down), then it is working against you at the exact moment you must accelerate — flatten it.
• If a smart creative deeply understands the data, technology, and context, then defer to their judgment over hierarchy, as Sergey did with Sridhar on AdWords.
• If the moonshot 'think big' talk is eclipsing methodical continuous improvement, then rebalance toward roofshots — the 1.3–2X gains like search's ~500 yearly launches.

• Assuming things are impossible instead of reasoning from real-world physics to what's possible — the tell: you dismiss a bet as 'wild' (like mapping every street) without checking feasibility.
• Keeping century-old command-and-control process because it 'lowers risk' — the tell: every decision waits for the few executives with comprehensive information while faster rivals ship.
• Listening to Silicon Valley lessons but never acting because you believe your company is too big or entrenched — the tell: lots of nodding heads, engaged conversation, and zero results.
• Hoarding data and compute as if they were still scarce — the tell: teams can't experiment freely because resources are gatekept.
• Over-glamorizing moonshots so continuous improvement gets neglected — the tell: real 1.3–2X accomplishments go unrewarded while only the sexy 10X projects get attention.

• ▸Information shift: how has free/ubiquitous data changed our customers' expectations?
• ▸Connectivity shift: what can users now do continuously via mobile that they couldn't before?
• ▸Compute shift: what pay-as-you-go cloud capability lowers our cost to build or experiment?
• ▸Cost of one experiment: dollars/days to prototype, test, and get real data.
• ▸Slowest process: which gate or approval most delays shipping, and why does it exist?
• ▸Speed metric: how fast do we currently iterate vs. how fast our field changes?
• ▸Big bet: one 10X moonshot we're placing on the future.
• ▸Roofshot: one 1.3–2X continuous-improvement gain we're pursuing now.
• ▸Empowered team/person: who can act directly on abundant data without escalating?

1. 1Diagnose your competitive moat honestly: if you're relying on marketing, distribution strength, or information control to prop up an adequate product, treat that as a liability, not an asset. Consumers now have full information and abundant choice, so the product itself carries the business.
2. 2Hire the best engineers and smart creatives you can, then get out of the way rather than governing them with a prescribed plan. Google fended off Microsoft not with an MBA-style business plan but by putting top engineers in an environment where they could succeed at scale.
3. 3Run a portfolio of roofshots and moonshots. Commit the bulk of continuous effort to methodical 1.3–2X improvements shipped relentlessly, while reserving separate ambition for 10X bets so the glamorous moonshots don't eclipse the compounding daily work.
4. 4Ship improvements continuously in high volume—treat launches as a stream, not events. Google search launches roughly five hundred improvements every year; that cadence is the mechanism by which small steps accumulate into something over 10X better.
5. 5Drop experimentation cost to near zero so more product bets are cheap to try and cheap to kill. A small team of engineers, developers, and designers should be able to build and distribute globally for free, inverting Bezos's ratio: 70% building the product, 30% shouting about it.
6. 6Break your own processes when they starve a promising product—give it a separate budget logic (potential future market value, not this year's revenue), independent decision-making, and its own hiring and launch process.
7. 7Provide air cover: assign a senior leader with authority to protect the rule-breaker from the corporate antibodies who drop rocks on anyone climbing a different mountain.
8. 8Let products that aren't good enough die a deserved death instead of rescuing them with brand and PR; free the freed capacity for the next iteration.

John Hanke joined Google in 2004 via the Keyhole acquisition (the tech behind Google Earth) and led geo products, but by 2011 he was restless with an idea: a gaming platform combining mobile phones, Google Maps, and augmented reality to play digital games in the physical world. He planned to leave to start it, but Larry Page told him to build it inside Google instead. They set up Niantic Labs as an autonomous unit with a separate compensation structure, independent decision-making, its own hiring practices and offices, the ability to work unfettered across Google product teams ("breaking walls"), and a streamlined launch process—about as close to a start-up as a big company allows. Niantic shipped Field Trip, then in 2012 the multiplayer game Ingress, a moderate success. That sequence of iterations paved the way for the Pokémon Go craze. The pattern is roofshot-style: repeated shipping under a process built for speed, not a single giant leap.

• If a product isn't good enough on its own merits, then let it die—don't try to save it with marketing or brand (Notebook, Knol, iGoogle, Wave, Buzz all died deservedly).
• If moonshot rhetoric is drowning out steady 1.3–2X gains, then reweight attention back toward roofshots—continuous improvement is just as important, only less glamorous.
• If a promising new product can't move the core's bottom line and keeps losing internal budget fights, then break the process and fund it on future market value rather than this fiscal year's revenue.
• If you break a process for a team, then attach senior air cover with authority to fend off the antibodies, or the rule-breaker gets crushed.
• If the founders or engineers intuitively grasp the new-era dynamics, then guide but don't hem them in with rigid planning structures—as Larry told Jonathan, boxing them in "would be stupid."

• Betting that brand and marketing will carry a mediocre product. Tell: leadership says "we'll out-market them" (Excite@Home did, and it's gone); the tailwind of PR can't overcome a headwind of mediocrity.
• Over-glamorizing moonshots so the relentless 1.3–2X work goes unrewarded and understaffed. Tell: everyone talks about the 10X bets, nobody celebrates the five-hundred-launches-a-year grind.
• Governing smart creatives with a prescribed, MBA-style plan. Tell: the plan reads like an alien organ the culture rejects, and it fails to motivate, attract talent, or address the industry's real dynamics.
• Applying core-business budgeting logic to a new venture—ranking by IRR/NPV and doling cash until it runs out. Tell: a leader like Susan realizes she could raise the money from VCs in days but can't get it internally because the venture 'won't move the bottom line.'
• Breaking a process without air cover. Tell: the rule-breaker is climbing while people drop rocks on them—antibodies attack and the effort stalls despite a good idea.

• ▸Product name and the technical insight it's built on: state the specific capability or data that makes it possible.
• ▸Merit test: is it good enough to win on its own, without marketing crutches? (yes/no + evidence)
• ▸Roofshot cadence: what 1.3–2X improvements will ship this quarter, and how many?
• ▸Moonshot separation: which ambitious 10X bet is being kept distinct so it doesn't crowd out the roofshots?
• ▸Experimentation cost: what does one build-and-ship test cost in people and time? (target: near zero)
• ▸Process breakpoints: which internal processes (budget, hiring, launch) currently slow this product, and which will you break?
• ▸Budget basis: are you funding on this-year revenue or on potential ultimate market value? (state the number)
• ▸Air cover: which senior leader has authority to protect this team from antibodies?
• ▸Kill criterion: what user signal will tell you it isn't good enough and should be allowed to die?

1. 1Set a moonshot goal that is 10X your current baseline, then decompose it into a chain of roofshots—1.3–2X improvements you can ship every quarter. The math: 1.3X per quarter compounds to 10X within three years.
2. 2Anchor strategy on a technical insight, not a business plan or market research. Business plans matter far less than the pillars they rest on; build on a defensible insight about technology or user behavior.
3. 3Hire independent thinkers ('learning animals') first, because sustained success comes from continuous product excellence, and product excellence comes from the 'primordial ooze' of the right people combusting into creativity.
4. 4Ship-and-iterate in small, frequent increments so teams get fast gratification—working things that make a difference—rather than betting everything on giant leaps that may never see daylight.
5. 5When a new venture can't 'move the bottom line' of the core, break your own processes: budget by the venture's potential ultimate market value years out, not this year's revenue. Provide senior 'air cover' to fend off the antibodies.
6. 6Watch for incrementalism creeping in as you grow—comfort with 'what we've always done' leads to irrelevance in technology, because change is revolutionary, not evolutionary. Restructure or spin out speculative bets so they operate with their own culture and financial pressure.
7. 7Source insight from outside when internal efforts fall short. Judge acquisitions on product and organizational value, not just financial or legal terms, and staff leadership that is comfortable acknowledging internal limitations.

YouTube shifted its core metric from video views to watch time, then set a moonshot goal of one billion watch hours per day—against a global TV total of about 10 billion hours per day and its own baseline of just over 100 million hours per day, making it a genuine 10X target. Rather than chasing that in one leap, the team focused almost entirely on 1–2X projects, which proved effective. Separately, Susan (running YouTube inside Google) hit Google's budget process, which allocated operating expenses in proportion to revenue—efficient, but hostile to a growing venture that she valued by its ultimate future market value, not this year's revenue. The fix was to break the process with senior air cover. The same pattern shows in Google search (roughly 500 improvements shipped every year) and the data centers that began as a pile of machines in rented cages: both now look like moonshots because they are over 10X better, but they got there through lots of small steps.

• If a goal assumes something is impossible, then reset it from real-world physics and figure out what's actually possible before deciding it can't be done.
• If you have a 10X ambition, then have most people work on 2X ideas driven by that goal—only a tiny fraction (like X) should work on true moonshots.
• If a noncore venture can't move the core's bottom line, then don't assess it by the core's numbers or IRR/NPV; budget it by potential ultimate market value and give it air cover.
• If your company is slowing down and becoming process-driven with only incremental change, then treat that as the warning sign of impending irrelevance and act structurally.
• If an outside company's product beats your internal effort, then judge the acquisition on product and organizational value and be willing to acknowledge the internal failure.

• Over-glamorizing the 10X moonshot dogma at the expense of methodical 1.3–2X roofshots—the tell is that ambitious ideas go on the to-do list but nothing ships and teams get no gratification.
• Letting the budget follow revenue instead of future value—the tell is a promising internal venture starved of investment it could raise from VCs in days if it were independent.
• Incrementalism: getting comfortable doing what you've always done with a few tweaks—the tell is process-heavy behavior 'when things are going well' and a creeping loss of relevance.
• Not-invented-here bias—the tell is leaders unwilling to acknowledge internal limitations and reflexively preferring internal projects over superior outside ones.
• Listening but not acting—the tell is the 'avuncular' response: nodding at the principles, calling them interesting but 'practically impossible to implement.'

• ▸Moonshot goal (10X): the audacious end-state and its multiple over today's baseline
• ▸Current baseline metric: today's number on the metric that actually matters
• ▸Quarterly roofshot target: the 1.3–2X improvement shippable this quarter
• ▸Technical insight: the pillar this bet rests on, not the business plan
• ▸Time-to-10X check: quarters needed at your compounding rate (1.3X/qtr ≈ 3 years)
• ▸Ultimate market value: the venture's worth years out, used to size the budget
• ▸Air cover: the senior leader authorized to break the process for this bet
• ▸Ship cadence: what working increment ships and when to give teams fast gratification
• ▸Irrelevance guard: the incrementalism warning sign you'll watch for and act on

1. 1Start with the founders' actual values, then expand them with the different perspectives and experiences of the early team — do not outsource the drafting to HR or PR after the fact.
2. 2Run the litmus test on every candidate value: ask what would happen if you reversed it. If flipping it would draw a chuckle and cause no operational change, cut it — it is decoration, not culture.
3. 3Write the values in a simple, concise way, imagining a specific decision moment: an employee working late, unable to make a tough call, walking to the kitchen for coffee. The values must plainly outline what matters most so they help that person make the right call.
4. 4Codify at a moment of consequence, not convenience. Google used its 2004 IPO — Larry and Sergey drafted a 'letter from the founders' for the prospectus (inspired by Buffett's Berkshire letters) and fought the SEC and their own lawyers to keep it.
5. 5Communicate the values constantly through authentic channels — over lunch, at all-hands, demonstrated by respected veterans — not posters and guides. Reinforce them with rewards, per Jack Welch: no vision is worth the paper unless communicated constantly and reinforced.
6. 6Build forums where employees can openly dissent, so belief in the values is tested and visible — Google's weekly TGIF is hosted by Larry and Sergey, and employees are welcome to voice disagreement with company decisions.
7. 7Answer hard questions honestly, and protect the askers. When Googlers grilled Motorola about its products at TGIF, Jonathan reassured worried Motorolans that no one would be fired for asking.
8. 8When redefining an existing culture, name the real culture people live in (not the stated one), connect specific business failures to it without insulting people, then take high-profile steps toward the new culture — open calendars, more all-hands, honest Q&A without reprisal.

Google's stated value 'Focus on the User' passes the reversal test that Enron's 'Respect, Integrity, Communication and Excellence' fails. If Enron had swapped its motto for 'Greed, Greed, Lust for Money, and Greed,' it would have drawn chuckles but changed nothing about how the company actually operated — the words were inert. By contrast, if Google reversed 'Focus on the User' by putting advertisers or publishing partners first, inboxes would flood and outraged engineers would take over the company-wide TGIF meeting hosted by Larry and Sergey. That reaction is the proof the value is genuinely believed and lived, not conjured by marketing people 'with a six-pack and a thesaurus.' The contrast is why David Packard's 1960 claim — that companies exist to 'do something worthwhile,' to make a product or give a service of value — reads as authentic while Lehman Brothers' box-checking mission ('unrivaled partnerships... superior results for our shareholders') told you nothing about what it stood for, right up to its 2008 bankruptcy. Because employees always have a choice, you belie your values at your own risk.

• If flipping a stated value would cause no real reaction or operational change, then delete it — it is corporate-speak, not culture.
• If you can't recite your own mission statement or don't believe it, then assume employees can't either — their BS detectors are finely tuned to when you don't mean it.
• If a value would help a bleary-eyed employee make a genuinely hard call at midnight, then keep it; if it's meaningless in that moment, it isn't worth a damn.
• If you're redefining culture, then diagnose the real lived culture and tie it to specific business failures — do not simply criticize it, which only insults people.
• If an old cultural artifact no longer serves its original purpose (like IBM's blue-suit dress code meant to show customer respect), then scrap it while preserving the founder's core beliefs behind it.

• Documenting culture only after success arrives, handing the job to someone in HR or PR who wasn't a founder — the tell is a mission full of 'delighted' customers, 'maximized' shareholder value, and 'innovative' employees.
• Writing values that check every stakeholder box (clients-check, employees-check, shareholders-check) but say nothing specific — the Lehman Brothers pattern, where you couldn't tell what the company stood for.
• Broadcasting values through posters and guides instead of constant authentic communication — Welch's warning that a vision unreinforced isn't worth the paper it's printed on.
• Stating a value you don't actually live by; employees have a choice and will head for the exits, so you belie your values at your own risk.
• Punishing or being seen to punish people who ask hard questions — the tell is employees quietly wondering whether the questioners will be fired, which teaches everyone to stop dissenting.

• ▸Founding value: state one value in the founders' own words, not marketing's.
• ▸Team-expanded version: rewrite it enriched by the early team's perspectives.
• ▸Reversal test: write the opposite of this value in one line.
• ▸Reaction if reversed: describe what employees/customers would actually do (chuckle-and-nothing = cut it).
• ▸Midnight decision it guides: name one hard, real call this value would resolve.
• ▸Lived-vs-stated gap: does daily behavior match this value? Cite one example either way.
• ▸Communication channel: where and how is this reinforced constantly (not posters)?
• ▸Reward link: what behavior tied to this value gets recognized or rewarded?
• ▸Dissent test: can an employee challenge a decision that violates this value without reprisal? How?

1. 1Start with the technical insight, not the plan: identify one or more technologies that can be applied in a new way to solve a big problem. This is the primary thing you evaluate before any business strategy or financial model.
2. 2Distinguish the insight from the market: don't ask what customers say they want (they'll ask for 'faster horses'). Ask what becomes possible now that a technology has shifted, and whether that possibility solves a large problem.
3. 3Build the insight so it can spread: expose it to other teams. When Jim McFadden built his linear-regression-at-scale capability, he wrapped it in an API so other programs could access it — the insight compounded once it was reachable.
4. 4Optimize the venture for growth, not current-year revenue: size the budget against the ultimate market value of the venture years out, not the operating expenses justified by this year's revenue.
5. 5Default to open: build platforms other developers and teams can work across ('breaking walls'), rather than closed products walled off inside one team.
6. 6Give the insight a strong leader and air cover: pair the technical insight with a CEO who can lead an entire venture, and shield them from process (expired-salt safety checks, peripheral PR docs) so they spend all their time on the product.
7. 7When evaluating acquisitions or new units, run the discussion on product drivers and insights — 'Do we have the right insights, or has the market or technology shifted?' — and only secondarily on financial and legal terms.

A Google research engineer, Jim McFadden, wanted to observe anonymized user behavior and run linear regression on it at massive scale to customize user experiences — call that insight #1. Rather than keep it siloed, he built an API so other programs could tap the capability. YouTube engineers heard about it and applied it to recommending what video a user should watch next; when they shipped the change, video views jumped noticeably. The insight then traveled again: Cristos Goodrow, arriving at YouTube from commerce, reframed the target metric the way commerce measures success. The point is that none of this began with a business plan or an IRR ranking — it began with a technical capability applied in a new way, which then found problems to solve as it spread. Contrast this with YouTube's budget fight: Susan Wojcicki argued the 2015 budget should be an investment sized to YouTube's ultimate market value, not operating expenses doled out by last year's revenue.

• If you're evaluating a new venture or acquisition and you have a financial model but no strong technical insight, then don't fund it — the insight is the primary signal, the model is merely necessary.
• If customers are asking for an incremental improvement ('a faster horse'), then treat that as a signal to look for a technology shift they can't see, not as a product spec.
• If a capability might help other teams, then expose it via an API/platform and default to open — closed only when there's a specific reason.
• If a new venture's value can't move the core's bottom line this fiscal year, then judge it on potential ultimate market value years out, not on this year's IRR/NPV.
• If process is overriding common sense and people have stopped thinking (the 'lost muscle memory' tell), then ignore the process for that venture and give the leader air cover.

• Leading with market research or a business plan instead of a technical insight — the tell is a polished financial model attached to an idea nobody can explain as a novel application of technology.
• Assessing new ventures by how they move the core's numbers — the tell is the phrase 'why bother, it won't move the bottom line,' which almost always favors reinvesting in the core.
• Budgeting a growth venture by allocating opex to current-year revenue — the tell is the MBA finance ranking of projects by IRR/NPV/CUF and doling cash until it runs out.
• Defaulting to closed and not-invented-here — the tell is leaders dismissing outside insights (acquisitions like YouTube, Waze, Android) because internal efforts should have produced them.
• Letting entrenched process trump judgment so people depend on it to decide for them — the tell is safety or PR steps applied where they make no sense, and staff who stop thinking because the process 'handles it.'

• ▸Technical insight: state the one+ technologies applied in a new way to solve a big problem (one sentence).
• ▸Big problem solved: name the large problem this addresses, not an incremental improvement.
• ▸Not-a-faster-horse check: what shift makes this possible now that customers can't articulate?
• ▸Open/platform plan: how will you expose this (API, breaking walls) so others can build on it?
• ▸Growth sizing: estimate ultimate market value years out — not this year's revenue-based budget.
• ▸Leader/CEO: who has the audacity and talent to run this as a venture, and what air cover do they need?
• ▸Process to ignore: which core-company processes must be waived for this to move at start-up speed?
• ▸Insight/shift review: do we still have the right insights, or has market/technology shifted fundamentally?

1. 1Define the smart creative you are hiring against: technical depth plus business savvy plus creative flair, an expert in doing who builds prototypes rather than just designing concepts. Screen for this composite, not for a narrow specialty.
2. 2Expand the aperture before you screen. Because everyone knows someone great, source referrals from your existing people and cast wider than resumes that match a job description, favoring generalists and independent thinkers over role-fit specialists.
3. 3Apply the learning-animal test: probe whether the candidate starts from real-world physics to figure out what is actually possible rather than assuming things are impossible. Larry Page notes it is 'tremendously hard to get teams to be super ambitious' because most people haven't been educated in moonshot thinking, so hunt for the exception.
4. 4Run interviewing as a committee skill, not a solo gate. Have an opinion, schedule interviews for thirty minutes, and route candidates through peers so the decision is peer-based and data-rich, not manager-driven.
5. 5Decide with data across the committee, and beware the bobblehead yes — the assenting nod that hides real disagreement. Insist it be safe to tell the truth so a weak candidate is actually flagged.
6. 6Refuse the urgency trade. When a role is burning, do not lower the bar to fill it fast; the passage principle is that urgency of the role isn't sufficiently important to compromise quality in hiring.
7. 7Hold the friends line: friends don't let friends hire (or promote) friends. Keep the relationship out of the quality judgment.

Google's founders were, by their own admission, great leaders of computer scientists but did not know how to build a company to their ambitious scale — so the hiring problem wasn't 'find more coders,' it was 'we needed more than computer scientists to create a great company.' Rather than write Moritz's prescribed business plan and hire to fill defined roles, Eric and Jonathan concluded the way to fend off Microsoft was continuous product excellence, and that excellence came from hiring the very best engineers and getting out of the way. The bet paid: Microsoft reportedly spent nearly $11 billion on MSN Search, Windows Live, Bing, and aQuantive and none achieved prominence — 'not because they were poorly executed but because Google was so well prepared for them.' Page ties this directly to hiring: 'It's why we've put so much energy into hiring independent thinkers at Google, and setting big goals. Because if you hire the right people and have big enough dreams, you'll usually get there.' The through-line: hire multidimensional learning animals against the ambition, not narrow specialists against a job spec.

• If a candidate assumes something is impossible rather than reasoning from what's actually possible, then they fail the learning-animal test regardless of credentials.
• If the role is urgent but the candidate is below bar, then leave the seat open — urgency does not justify compromising quality.
• If the candidate is a friend of the hiring manager, then remove that manager from the quality decision; friends don't let friends hire friends.
• If a strong proven leader wants to start something new, then find a way to keep the talent (John/Niantic: independent decision-making within Google) rather than defaulting to losing them.
• If interview feedback is all agreement with no dissent, then suspect a bobblehead yes and force someone to surface the real objection before you decide.

• Hiring narrow specialists to match a role definition — the tell: your job spec reads like a task list and your best candidates would 'get bored easily' the moment the task changes.
• Lowering the bar because the seat is empty — the tell: the justification is 'we need someone now,' not 'this person clears quality.'
• Letting the hiring manager decide alone — the tell: no peer committee, no shared data, one person's gut carries the offer.
• Confusing polite consensus for a real yes — the tell: everyone nods (the bobblehead yes) and no one names a weakness, because it wasn't safe to tell the truth.
• Betting on brand or marketing to carry a weak hire's output — the analog of Excite@Home's 'we'll out-market them'; the tell: you rationalize a mediocre candidate as good enough because the team's reputation will cover for them.

• ▸Ambition being hired against: state the big goal this person serves, not the role title.
• ▸Technical depth evidence: what have they actually built (prototypes, shipped work), not designed.
• ▸Business-savvy evidence: where they connect technical work to product and business outcome.
• ▸Learning-animal signal: an instance where they reasoned from possibility instead of assuming impossible.
• ▸Aperture source: how you found them beyond resume-match (referral, wider net).
• ▸Committee verdict + dissent: each interviewer's data-backed call AND the strongest objection raised.
• ▸Urgency-vs-quality check: is any yes leaning on how badly you need the seat? (yes/no + why)
• ▸Friendship conflict flag: any personal relationship to the decider? If yes, who is recused.

1. 1Set the default: share board letters, OKRs, snippets, and product plans as widely as legally possible, so that closed is the exception you must justify, not open. Adopt the rule 'default to open, except when…' — closing only where regulation, privacy, or competitive harm requires it.
2. 2Give everyone a live status artifact. Copy Google's ranked spreadsheet of the top ~100 projects: visible to anyone, prioritized 1–5 with room for 'new/far out' and 'skunkworks,' and debated in recurring resource-allocation meetings.
3. 3Run a standing all-hands where any topic is fair game. Google's Friday 'TGIF' let founders push a small number of consistent messages ('the profound importance of the Internet and the power of search') directly to teams.
4. 4Act as a router, not a gatekeeper: optimize information flow. Treat your job as moving the right detail to the right person quickly rather than hoarding data to preserve status — remember data and computing are now abundant, so there's no need to hoard.
5. 5Make it safe to tell the truth: start the conversation yourself, invite dissent, and reward people who surface bad news or acknowledge failure (the humility that let Google shut down Google Video for YouTube).
6. 6Repeat the core messages relentlessly — 'repetition doesn't spoil the prayer' — because the message only lands after you're tired of saying it. Pair repetition with 'know the details' so your communication is credible.
7. 7Prioritize relationships over hierarchy: route through the people who actually know, not the org chart, and let ideas and information come from anywhere.

Google's primary management tool for years was a single spreadsheet: a ranked list of the company's top 100 projects, open for anyone to see and debated in semi-quarterly meetings that were part status update, part resource allocation, part brainstorming. Prioritization was crude — most projects scored 1 to 5, with extra buckets for 'new/far out' and 'skunkworks' — and there was no longer-range plan; if something more important surfaced, engineers adjusted the list themselves. This is open communication as an operating system: the information regime is visible by default, so anyone can see priorities, challenge them, and reallocate. The founders reinforced it with informal engineering meetings and weekly TGIFs where any topic was fair game, using communication 'as a tool to keep everyone moving in the same general direction.' The point wasn't a perfect ranking; it was that everyone shared the same visible facts and could argue about them openly.

• If information isn't legally, competitively, or privacy-constrained, then default to open — closing requires an explicit justification.
• If a project's priority is unclear, then put it on the shared ranked list and debate it in the open rather than deciding privately.
• If someone brings you bad news or admits a failure, then reward the honesty first — otherwise you train people to hide the truth.
• If an outside solution beats your internal effort (YouTube over Google Video, Waze alongside Maps), then acknowledge it openly; not-invented-here is the tell you've closed communication.
• If a core message matters, then repeat it past the point of boredom — assume it hasn't landed until it's overheard back to you.

• Publishing values or a mission you don't practice: 'Respect, Integrity, Communication'-style corporate-speak (Lehman Brothers' polished statement before bankruptcy). Tell: people can't recite it or don't believe it — BS detectors fire.
• Openness without detail — routing information you don't actually understand. Tell: you can't answer follow-up questions, so credibility and flow collapse.
• Bobblehead agreement: sharing widely but punishing dissent, so people nod instead of telling the truth. Tell: meetings produce consensus with no visible disagreement.
• Routing through hierarchy instead of relationships: information waits for the org chart. Tell: decisions stall because the person who knows isn't in the loop.
• Hoarding data to protect status even though data and compute are now abundant. Tell: leaders treat access as a reward and juniors can't see priorities or plans.

• ▸Shared artifacts — which of board letters/OKRs/snippets/product plans are open by default (list them)
• ▸Access scope — who can see each artifact today; note anything closed and why
• ▸Closed-with-cause log — the specific legal/privacy/competitive reason for each exception
• ▸Standing forum — your TGIF-equivalent, cadence, and 'any topic fair game' rule
• ▸Ranked project list — top projects, 1–5 priority, plus 'far out'/'skunkworks' buckets, owner of the review
• ▸Core repeated messages — the 3–5 points you say until bored, and where you say them
• ▸Truth-safety practices — how you start the conversation and reward bad news/failure admissions
• ▸Routing map — who actually knows what (relationships), not the reporting lines

1. 1Assemble the decision around data, not opinions. Before the meeting, require the sponsoring team to bring the financial metrics and, more importantly, the product drivers behind the proposal. As the decisions chapter puts it: decide with data.
2. 2Establish the obligation to dissent as a rule, not an option. Every participant—including naturally reticent ones—is expected to raise contrary views in the room. The point is to take on the hippos (highest-paid person's opinions) so decisions rest on merit, not seniority.
3. 3Lower the filter so ideas reach the table. Copy the deal-review model: as long as one product lead is willing to sponsor a deal, it lands on the docket even if others harbor serious concerns. Do not let a multilayer scrubbing process kill the discussion before leaders can debate whether the target is doing something interesting.
4. 4Convene the right people and drive true consensus—thinking together, not unanimity. In deal review that room includes Larry Page, Sundar Pichai, and most other leaders; the M&A team frames financials, then the balance of time goes to product drivers led by the product team.
5. 5Watch for and reject the 'bobblehead yes'—apparent agreement that masks unspoken doubt. Surface the real disagreement instead of accepting nods.
6. 6Name a single decision-maker who knows when to ring the bell. After genuine debate, one person closes it. Larry's Alphabet move is the template: he moved quickly, didn't have all the answers, but knew he had to act, then didn't look back.
7. 7Enforce disagree-but-commit once the bell rings. Dissenters get their say fully, but after the decision the whole team executes it as their own.

Google's weekly deal-review meeting shows the model running. In most companies M&A is a finance-driven, multilayer process where corp dev scrubs the deal financially and only a pre-cleaned proposal reaches the CEO for approval, so leaders never discuss whether the target is actually doing something interesting. Google inverts this: product teams work with corporate development to suggest targets, the necessary financial and legal reviews still happen, but as long as a product lead sponsors the deal it reaches the docket even if others have serious concerns. At the meeting—with Larry Page, Sundar Pichai, and most other leaders present—the M&A team introduces the company and its financial metrics, then the group spends the balance of the time on the product drivers, a discussion the product team leads. This keeps data (financials) as the floor while forcing a genuine, senior debate about the strategic and product insight. It also functions as a test of Google's own product strategies against the best companies emerging in the field. The design deliberately preserves the discussion that finance-first scrubbing would have quietly eliminated.

• If a single product lead will sponsor an idea, then it goes on the docket—even over others' serious concerns—so the room actually debates it.
• If financial and legal reviews are done, then don't stop there: spend the balance of the time on the product drivers, because that's where the real insight lives.
• If someone gives a 'bobblehead yes,' then treat it as unresolved dissent and pull the real objection into the open before closing.
• If genuine debate has run and no new information is emerging, then the single decision-maker rings the bell and the team commits—don't reopen it.
• If process is now making the decision for people and judgment is weakening ('losing muscle memory'), then override the process with common sense and put a human back in charge of the call.

• Confusing consensus with unanimity. The tell: people keep debating to get everyone to agree, and the decision stalls—rather than thinking together and letting one person ring the bell.
• Letting a multilayer, finance-driven filter scrub deals before leaders see them. The tell: senior people never even discuss whether a target is doing something interesting because it was killed upstream.
• Accepting the bobblehead yes. The tell: everyone nods in the room, then the objections surface after the meeting or the commitment quietly fails.
• Making dissent optional. The tell: only the confident, senior, or extroverted speak; reticent people stay silent and hippos win by default.
• Over-relying on process so judgment atrophies. The tell: people stop thinking and depend on the process to decide for them, and common sense gets trumped—the pendulum stuck on the control side.

• ▸Sponsor: the single product lead putting their name on this (one is enough to reach the docket).
• ▸Data / financial metrics: the numbers the M&A or ops team presents up front.
• ▸Product drivers: the strategic and product insight this decision rests on—where the debate should spend most of its time.
• ▸Attendees who must dissent: named participants obligated to raise contrary views, including reticent ones.
• ▸Open concerns on record: serious objections others hold, listed so they aren't scrubbed away silently.
• ▸Bobblehead check: any 'yes' that feels like unspoken doubt—write the real objection here before closing.
• ▸Decision-maker who rings the bell: the one person who closes the call.
• ▸Decision & rationale: what was decided and why, captured the moment the bell rings.
• ▸Commit list: who now owns execution under disagree-but-commit.