If you’ve ever watched brilliant engineers build amazing things that never see the light of day, you know the feeling. It’s the quiet, grinding frustration of working in a company where talent is abundant but something is fundamentally broken. That frustration is the entire point of Steve Yegge’s legendary 2011 rant about Google’s platform failure. But most people read it wrong.
Yegge’s rant is usually treated as a Google takedown—a story of how Amazon built AWS while Google fumbled. But the real story is more unsettling. Platforms are an org-design outcome, not a technical one. Amazon didn’t succeed because it was smarter. It succeeded because its internal incentives forced teams to externalize their capabilities. Google, for all its brilliance, was structurally incapable of seeing the platform forest for its product trees.
Let’s talk about the Amazon side first, because it’s the part everybody gets wrong. Amazon is celebrated for developer-friendly infrastructure. But Yegge’s own comments—and the top comment on his rant—paint a different picture. At Amazon, engineers are starved for internal tools. One senior engineer found a bug in the tokio library and had to spend hours fighting bureaucracy to fix it. The clearest example: Amazon’s own developers struggle with tunnel vision. The higher-ups don’t understand how much money they’d make if they fixed internal pain points. Amazon is the gold-standard platform company, and it still fails its own developers every time leadership can’t count the value.
Now look at Google. Brilliant engineers. Open-source culture. Deep pockets. And yet, no platform. Why? Because Google’s internal incentives were product-centric. Teams were rewarded for shipping features, not for building shared infrastructure. The API mandate that Jeff Bezos drove at Amazon? Google never had that. Instead, each team optimized for its own product, and the result was a collection of isolated services that never coalesced into a platform. Neutrality is death in platform strategy. Google stayed neutral on internal incentives, and it died a thousand product deaths.
This is where Yegge’s rant becomes a universal law of platform strategy. The question isn’t, “How smart are your engineers?” The question is, “Who has the decision rights to build shared infrastructure?” At Amazon, the answer was forced by a mandate. At Google, the answer was nobody. And that’s why AWS exists, and Google Cloud is an afterthought. The best engineers in the world can’t overcome broken incentives.
So what does this mean for you? If you’re in a tech company—big or small—this is your early-warning radar. Look at how your leadership allocates resources. Are they investing in internal platforms and developer tools that don’t have a clear product owner? Or are they shipping features that impress customers but leave your own engineers stuck in silos? If your leadership isn’t intentionally building shared platforms, your work will be trapped in internal silos—regardless of how smart the people around you are.
Take a side: Amazon’s platform success is a story of organizational design, not genius. And Google’s failure is a warning that brilliance without structure is just noise. The next time you hear a tech company talk about “platform strategy,” ask who’s accountable for the internal APIs. The answer will tell you everything.
FAQ
Q: Didn't Google eventually build a platform with Google Cloud?
A: Yes, but it was a late, expensive pivot. The rant is about the missed opportunity in the 2000s when Amazon had already locked in the lead. Google's internal culture made it hard to build a unified platform until it was almost too late.
Q: What's the practical takeaway for a startup founder?
A: Create an API mandate from day one. Force every team to expose their capabilities as services. If you wait until you're big, the silos are already baked in. And measure the value of internal platforms—don't let them die because they don't have a revenue line.
Q: Isn't Amazon's internal tooling actually terrible?
A: Yes, that's the paradox. Amazon's external platform is great, but internally engineers are often frustrated. That's exactly the point: platform success doesn't mean internal happiness. It means the organizational structure forces externalization, even if it's painful internally.