That also explains why the breadth of AWS services keep growing, but the depth of the existing ones remains the same. Seems they would, every 4 years, lose a bunch of people with deep knowledge in the existing ones, the ones who'd be able to add new and deep features.
The back-ended equity structure (i.e., you only vest 5% of your equity grant in the first 12mo) isn’t great when you’re comparing it with a standard vesting schedule as an employee. As an employee if you’re given two identical grants for two identical companies with the same future prospects then you take the one that gives you that equity sooner. But the rhetoric is usually that equity is meant to be an employee retention tool. So from that perspective the AMZN vesting structure makes much more sense to me than what is common elsewhere.
As for the service dynamic: the whole “2 pizza team” thing is both a blessing and a curse IMO. Once you launch a service at AWS’s scale you’ve immediately got tens of thousands of users. And AWS takes stability/availability/scalability incredibly seriously. I think it’s more likely that team is now in a permanent operations mode fixing weird edge cases you find at scale and keeping the lights on.
If it was a staff retention issue like you suggest then you’d see the platform plagued with reliability issues and services being shut down. But that doesn’t happen. Even SimpleDB is still available for use (though well hidden).
I mean, just look at the Amazon retail operation - everyone agrees that the website is tired, ugly, and slow, but lots of people still do all their shopping from there because they're used to it and it's easier than maintaining accounts with 15 different retailers with 15 different websites. Amazon's bottom line seems to indicate that breadth-first algorithms work well on problems involving human populations.
> where so much of revenue comes from the relatively few customers who are very deep in their usage.
I'm disputing that for retail.
This was Microsoft’s strategy way-back-when. You can go surprisingly far, especially in enterprise, by covering all the basics without excelling at anything in particular, and fixing your mistakes.
Avoiding fatal flaws is really really important and is extremely difficult to do, so just managing to be mediocre at everything necessary is actually quite uncommon in my experience.
I have seen this particularly in my limited experience of founders and startups: you may need to be great at one thing, but you also need to be OK at many many things, and you must avoid the infinite sea of fatal flaws.
Slow compared to what? Amazon's website feels more responsive and more usable than 90% of online stores I've seen that carry orders of magnitude less variety of inventory. It loads fast, searches fast, provides for easy navigation between related products, and displays all needed information on one page without jank. Sure, it doesn't look modern, but it feels far more functional than the competition.
I suspect their search, classification, filters etc are all so broken because it's all based on a Google-style textual search, with no backend database driving those site features.
AWS never cancels anything... but they never complete anything either and they abandon 80% of their products in minimum viable state, where "viable" is defined by the PM's bonus packet, not by anyone who has to use the damn thing.
IAM support was essentially useless, you had to create second set of accounts inside Quicksight, with various limitations, and generally it was one hell of a mess.
All of this because the policy language and featureset started off simple enough that it was reasonable to describe policies in json. I sort of wish that they would keep the existing policy stuff as-is but have an escape hatch that let us write lua (or JS or eBPF or something) as "policies", and charge us for the compute time.
But then I actually blew the stack in IAM processing to the point we couldn't start an AWS sagemaker notebook because IAM died while attaching a network interface to EC2...
I'm glad we have bucket-owner-enforced now, but the correct time to add it was 10 years ago.
It's a cottage industry.
New services/businesses are how you get promoted. Maintenance or incrementally improve existing functionality and you'll never get promoted.
Amazon isn't really alone in that short sightedness though, it's just extra noticeable when combined with high churn
Can't win.
I know you didn't say #1, but both of these contradictory points are floated quite often.