Ex-Amazonian here, so take what I say however you will.

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).

That seems like a good (albeit cynical) strategy to be honest. 80% of your users only care about 20% of the features, and by offering as many different services as possible, you minimize the number of purchasing decisions that customers need to make. Are all your offerings just OK or even mediocre compared to the competition? Yes. Do most customers care? No, as long as it's adequate and doesn't actively cause problems. I can think of many purchase/usage decisions of my own where I prioritize convenience over optimization, because the apparent return from optimization exceeds the apparent cost.

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.

> Are all your offerings just OK or even mediocre compared to the competition?

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.

> 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

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.

Though the filtering features are pretty much useless for almost every product. Too many products to maintain any decent classification. That makes it pretty much useless for looking for computer hardware (that and counterfeit products).

So true, but I don't think it's impossible to maintain classification, that's just Amazon. I think they just gave up trying to, probably after they opened up up other sellers.

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.

Pricespy had excellent filters for the produxts they listed, though I guess it was more focused than amazon. I would say maintaining is possible, especially if they let retailers define the fields and responsible for filling them for the products they list.

Yet they could do much worse. By just not having multiple options merged into one item makes them better than the disaster that's eBay. In comparison they're not useless, because someone is doing it even worse.

Their local competitors in my country are so much better, and amazon shipping is so slow, I don't know anybody that actually uses amazon except for AWS.

Except it's full of terrible fakr products and shady overseas businesses and shady company policies which often screw the customer over and fake reviews everywhere. Tons of crap products that will break or not work instantly and shady companies who refuse to give a refund unless you provide a 5 star review. Their delivery service and prime is also a rip off, it's literally no longer worth it.

This actually seems like a structural weakness in cloud, where so much of revenue comes from the relatively few customers who are very deep in their usage. On the other hand, you can usually rely on close relationships with those customers to identify their significant needs. However, it might be harden to implement them without the bench of deeply knowledgeable engineers.

It seems unlikely to me that this analysis applies to amzn's retail division.

If you spend any time reading their retail forums [1], you'll see almost everyone lambasting Amazon constantly. Either disgruntled sellers who broke the rules and got terminated, or normal, hardworking mom-and-pop stores that were all but forced to sell on Amazon and consistently lose money due to amazon's ever-changing policies, poor support, and catering to large retailers. Large retailers get a direct line and quality support, while most sellers on Amazon get treated like crap.

[1]: https://sellercentral.amazon.com/forums/

The GP claim was

> where so much of revenue comes from the relatively few customers who are very deep in their usage.

I'm disputing that for retail.

If you view the sellers rather than the buyers as customers, then you’ll see that it is the case.

Or maybe it’s just a tiny fraction of those millions of sellers on their platform?

Who would bother writing on these forums unless they have an axe to grind?

The number of services is just crazy - I've worked with AWS solutions architects in trying to find the perfect solution to our particular problems, and even they don't seem to know what half the stuff does.

Let alone which ones are the good ones. That only comes from experience.

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.

And the level of actual integration of various services varies a lot (I mean, you expect things like IAM to be included if it's AWS service, right? Lol nope) plus then there's stuff that will be documented with something like one paragraph in docs and highly paid support engineers will never find anything internal about it, so you end up building a complete SSO solution for AWS from scratch...

AWS sometimes feels like Debian's APT but everything is rewritten in java.

AWS SimpleDB is in Erlang :p

What services aren't currently integrated with IAM / didn't launch with IAM integration?

AWS Quicksight was one, late 2020-early 2021 (which is about 5+ years after acquisition, iirc).

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.

Also when IAM integration is there it has patchy support for resource condition wildcards and condition keys which are usually not documented

Totally agreed there. Also condition keys have such a high cognitive load; I can never ever remember the exact spelling of them or whether I need StringEqual or StringIsEqualIfExists or whatever other operator. The documentation has tons of prose about what service-specific keys to expect, but nearly 100% of the time when I'm trying to do something non-trivial with IAM, I end up finding the answer on somebody's blog rather than the documentation.

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.

I recall that there was at least one case where two similar condition keys that by name should work both, only one was appropriate.

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...

S3 had poor integration with IAM until a few months ago.

I'm glad we have bucket-owner-enforced now, but the correct time to add it was 10 years ago.

Not true - they are finally turning off "EC2 classic" in August.

Kind of goes both ways, they might not have been very good architects.

I know a few certified "architects", and let's just say they are people whose career was built on talking, not building.

It's a cottage industry.

Maybe they stick around for only 4 years too.

EC2, Lambda, S3, EKS, and their prepackaged DBs and queues. That's about it.

That's more promotion oriented architecture and design.

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

Yes- this is real. There used to be “subclasses” to the Principal Engineer role and you could pick if you wanted to be a Depth Principal or a Breadth Principal, and that no longer exists now.

Too many features: code bloat from noob engineers Too few features: too many new apps from noob engineers

Can't win.

I know you didn't say #1, but both of these contradictory points are floated quite often.