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.
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.
> where so much of revenue comes from the relatively few customers who are very deep in their usage.
I'm disputing that for retail.
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.
Why would companies truly "value" Engineering? The majority of execs thinks we are just interchangeable drones and the only reason the salaries are so high in SV is because they literally can't get away with less. If they could, US salaries would be comparable to Canada or EU which are embarrassingly low for the amount of work they require.
They will fire you in an instant to save cost, never increase your salary and come up with elaborate schemes to basically screw you.
I have seen executives try it all: Replace senior engineering with students or interns (I'm not kidding), hire from third world companies and pay the peanuts, bring in cheap labor on visa restrictions and abuse them, low ball you in salary negotiations, attempt to pay with "stocks" (I'm talking about penny stock companies here..)
To management, Engineering is nothing but an annoying expense that gets in their way of profit.
All the free foods, foosball tables, "family" mantra and cool hats are designed to distract you from the fact that you are being paid in pittance. This is why there is so much discrimination against older engineers, because they are more likely to catch up to this and demand a fair wage and good working conditions. When you are young, naive and hungry, you don't think about it much because burning the midnight oil with pizza is exciting.
I think that misses a cultural difference, which is that Canada and EU jobs don't require as much work because our work ethic is different. I can earn 100k in London and be very comfortable doing less than 40 hours a week, never working weekends, never doing crunch time, never being forced to work overtime, taking 6 weeks of vacation every year, sometimes more, and half of that is legally mandated. I don't have to flat-share on 100k.
US salaries are extreme because the US work-ethic doesn't support that lifestyle. If you value your time more than your money then it's the US that provides an embarrassingly low return.
This sounds like 90% of the people I knew at Google.
> US salaries are extreme because the US work-ethic doesn't support that lifestyle.
This isn’t even remotely true.
The longest work day I've had is 40 or 50 hours without sleep to meet a deadline that and then had to be in bright and early the next morning. But there's been more then a few times a year that I ended up sleeping in the office because I missed the last 1:00am train out.
Not all Canadian companies are like that anymore then all American companies are like Amazon or Google. Nor do I claim to understand why this is the case, but at least from what I've seen, Canadian tech salaries do lag quite a lot compared to US salaries compared to the skill demanded.
> I can earn 100k in London and be very comfortable doing less than 40 hours a week, never working weekends, never doing crunch time, never being forced to work overtime, taking 6 weeks of vacation every year, sometimes more
This describes LOTS of engineers at big tech, just change 100k to 400k and 40 hours to 20
2022: everyone brags about working 20 hours a week
IT professionals in Ontario, at least, are probably exempt from most of your list of things you'd think are required.
Engineers and engineering students get an even shorter stick, in the form of more labour law exemptions.
https://www.ontario.ca/document/industries-and-jobs-exemptio...
This is pretty normal in the US too. Sure, its not "mandated" but everything besides 6 weeks of vacation is pretty common for SDE.
https://www.engadget.com/amazon-more-than-doubles-base-pay-f...
I can attest to this; worked there from mid 2000s to early 2010s. Principle Engineers, L7 ICs, were looked up as Gods back then. To an extent that a couple of projects by an L5 where it went through principal-review process was almost guaranteed to get them a promotion to L6. Back when I was there I thought pulling off L5-L6 required crazy work schedule (I couldn't so didn't) and L7 was well and truly beyond mortals.
But now I hear they are doling out L7s like candy as they are getting increasingly desperate to fill their open head counts. How times change!
In the AF, your performance reviews need to be "firewalled" or it's time to leave.
What does firewalling a performance review mean?
Levels.fyi doesn't seem to agree with your title inflation evaluation: https://www.levels.fyi/?compare=Google,Amazon,Microsoft&trac...
It's only 3 data points, but it seems that Amazon Senior is comparable to Google senior, and it's Microsoft that inflates the Senior title.
Gist: "junior" L6 SDE is more like Google L5, "senior" L6 SDE tracks mostly with Google L6 (or even L7 in rare cases).
I think it's more like Google junior L6 SDE is equivalent Uber L4.5, which itself is about the same as senior AA at Oracle (= like a L11 at Twitter).
https://bigtechnology.substack.com/p/standing-up-for-us-pleb...
However, anecdotes make up hopes.
While a viable business strategy, from a personal value perspective, if you are an average CS college grad, you are by far not going contribute even close to $150k/year worth of value - you are going to do some menial basic code modifications.
So by all means, while you can go and take advantage of the inflated salaries to maximize your own profit as much as you can, but you cannot claim that $150k starting salary is too low.
I've heard that the cultures are different between the two. I would expect AWS to value holding onto their most experienced engineers.
That still doesn’t make it acceptable. People are not Bezos’ minions slaving away so he can get even richer. Even Amazon employees deserve to be treated like humans, whether the abusive culture at amazon is a secret or not.
You left out a big part here; RSU vesting schedule is back loaded. It's something like 5-20-25-50
At the time of calculating an offer, all 4 years are considered the same "Total Compensation Target" i.e. no built in reduction or raise. Amazon just pays cash equivalents for years 1 and 2 - through a signing bonus to make up for the lack of stocks, and through stocks in years 3 and 4.
The stocks in for each year are calculated assuming an average of 15% growth. This can be problematic, or can be great depending on the year you join.
Disclaimer: Worked at Amazon for 9 years.
Yes, technically speaking, the stock only compensation is backloaded. But that is balanced out by a 2 year "signing bonus" that is front loaded an equivalent amount of money, such that you are almost getting a hybrid stock/signing bonus package, so that it is technically the same amount of compensation each year.