The priority paradox: why Google is brilliant at everything except what matters most

The priority paradox: why Google is brilliant at everything except what matters most

Google is an incredible company that keeps tripping over its own bureaucracy — and Deedy, who worked there, has a theory for why. In his telling, Google does a middling job at its first priority and crushes its second and third. Search aside, the pattern repeats across Google+, Assistant, Cloud, and now AI: the flagship effort stumbles while the neglected projects quietly become products a billion people can’t live without.

The mechanism is brutally human. When a company-wide priority is declared, the most ambitious people in the building see a gleaming promotion path — “Did you know Sergey is personally working on this?” — and the whole org turns into a knife fight for the highest-impact projects. Credit is fought over, concerns are hidden, metrics get juiced, and eventually more work goes into the promo packet than into the actual project. Goodhart’s law kicks in: the numbers measured for promotion are abused beyond measure. Quality, polish, risky innovation, and cultural cohesion are the casualties.

Meanwhile, the second and third priorities get left alone — and that is exactly why they work. They attract people with genuine interest and sincerity, people willing to play longer-term games, because there’s no promo crowd stampeding through. “Many products have grown and thrived when left alone,” Deedy writes. The flagship gets the politics; the side quest gets the craft.

There’s a quieter, more admiring thread in the essay too: Google continuously prioritises its users over profits. The company sits on some of the most widespread and under-monetised products in history — Search, Chrome, Android, Workspace, Drive, YouTube, Gmail, Maps, Photos, Translate, Gemini, Calendar, Meet, Waymo — and “software Google has made available for $0” is now inconceivable to live without. A casual reader could imagine a hundred ways to monetise it all. Google usually doesn’t. It launches experiments not when they’re high-engagement, Deedy argues, but when they’re actually good. That restraint is rare — and it’s also why “an incredible number of people leave,” as the un-Googley types who thrive in frenetic eras cash in and go.

• Beware the flagship effect. The moment something becomes the priority, it attracts promotion-seeking behaviour, not craft. The best work often happens two priorities down, where nobody is watching.

• Goodhart’s law is an org-design problem. When the metric is the promotion, the metric gets gamed. Measure the work, not the worker’s narrative about the work.

• Neglect is a strategy. Products that are left alone attract sincere people and long games. Some of your best bets deserve deliberate inattention from the promo machine.

Uber’s answer to agent chaos: one gateway for 5,000 tools

Uber published how it built its MCP infrastructure — and it reads like a field manual for the agent era. When hundreds of teams started wiring agents into thousands of internal services on their own, Uber ended up with fragmented tooling, undiscoverable tools, and plumbing coupled to single services. The answer was a single management layer: MCP Gateway, one orchestration and routing plane between every AI agent and every back-end service. It now hosts over 800 MCP servers and 5,000+ tools.

The design is a study in what infrastructure actually means when the users are agents. The gateway hides the differences between HTTP, gRPC, and TChannel behind one door, applies consistent security and observability, and makes tools easy to create, find, and reuse — no team rebuilds the plumbing. An automated crawler turns internal APIs into MCP tools with a single configuration change. SaaS integrations (Google, Slack, Jira) get hosting and token exchange handled centrally, so engineers have one installation method for everything. Internal and third-party tools ride the same rails.

Killing schema bloat

The cleverest part is the cost engineering. Standard MCP loads every tool’s schema into the model’s context up front — with 100+ tools installed, that’s roughly 50,000 to 70,000 tokens of overhead before the agent does anything, re-sent on every turn. Uber attacked it three ways: CLI projection, where the model runs a shell command that resolves the right tool at call time so schemas never sit in context; tool search, pulling in only the definitions relevant to the task, on demand; and code-mode, where the model writes a small script that runs a whole tool sequence in a subprocess and returns only the summary. Per-session schema overhead fell to near zero — and the fleet saved 40% on tokens. They even built ~25 pre-packaged “code-mode skills” so the efficient pattern is the default, not an opt-in.

The meta-lesson, via the write-up that travelled the timeline: treat the tool layer as infrastructure, not an afterthought. Everyone benchmarks models; almost nobody benchmarks the plumbing agents actually spend their context on. Uber did, and the methodology — benchmark real work, decompose the cost, re-optimise continuously — transfers even where the numbers don’t.

• Centralise the agent plumbing early. Team-by-team integrations feel fast and become a discovery and reliability tax. One gateway, one auth story, one observability plane.

• Context is the real budget. Schema bloat is a silent tax on every turn — resolving tools at call time instead of pre-loading them is the difference between 70k tokens and ~zero.

• Make the efficient path the default. Uber’s pre-packaged code-mode skills mean engineers get the cheap pattern without thinking about it.

The 98% problem: AI adoption is a product problem now

Ninety-eight percent of US households aren’t paying for AI yet — that’s a16z’s State of Markets II, and Madhu Guru’s gloss is the one to sit with: AI adoption is largely a product problem today. Even among the 2% who do pay, the depth of usage is shallow. The models are ready. The products are not.

His diagnosis of the shallowness is vivid: most AI products look like airplane cockpits with a hundred levers — connectors, permissions, model selection, token usage, API keys, context windows. Every lever is a decision the user didn’t want to make. Power users tolerate the cockpit; everyone else bounces off it. The depth-of-usage problem is really a cognitive-load problem: when the interface demands that you understand the machinery, only machinery-people show up.

The optimistic turn is the prediction: “Things will look materially different in the next 12 months as product teams come into their own and make AI products easier to use.” This is the classic technology diffusion script. The model layer had its decade; now the product layer gets its turn. The winners won’t be the labs with the best benchmarks — they’ll be the teams that hide a hundred levers behind one obvious action. It rhymes with the vertical-agent thesis from earlier editions: high-polish, single-life-area products beat generic horizontal assistants precisely because they remove decisions.

For anyone building, the 98% is the opportunity, not the indictment. Ninety-eight percent of households haven’t said no to AI; they’ve said no to the cockpit. The company that makes AI feel like a light switch instead of a flight deck gets the other ninety-eight.

• Shallow usage is a design signal, not a user failure. If even paying users stay shallow, the interface — not the intelligence — is the bottleneck.

• Count the levers. Every connector, permission, and model toggle is a decision you’ve outsourced to the user. Hide them or lose the 98%.

• The product decade starts now. The next twelve months belong to teams that make AI products easier to use — build for that window.

The Unread Pile — Edition No. 11. Built read-only from three new posts in your X likes & bookmarks (3–4 Oct 2026). Nothing was liked, bookmarked, or reposted in the making of this edition.

Originals: @deedydas · @santtiagom_ · @realmadhuguru