I'm a long time Amazonian. The big problem is legacy employees run every part of the company. Almost any manager of managers has been at Amazon a long time, in that same job for a long time. There is no upward mobility at the company, unless you have been in some org 5+ years. In Alexa, the people running the core ML teams have been in Alexa since it started. Most people in decision making positions just got there first (10-15 years ago)
The software engineering paradigms used within the company create brittle rube goldberg machines of events flowing everywhere in the company. Almost all of them are on maintenance mode, where the oncall burns out the engineers and prevents them from creating new products. There is no knowledge sharing between team members. Legacy team members guard their technical platform knowledge to solidify their place on the team.
The engineers themselves are not students of computer science, but just crunch out tickets.
If Amazon wants to change they need to remove a significant amount of tenured employees, and actually promote young engineers into decision making positions.
AWS hasnt released an innovative product in a really long time
> There is no upward mobility at the company, unless you have been in some org 5+ years
Sometimes I try to talk to my 83 year old dad, who was a Teamster at the same company for his entire 35 year career, about the software industry. He's so surprised how often people like me change jobs, how we switch companies as a way to get a raise, and just generally how different expectations are. When I told him about how I'd left a company partly because they didn't promote me after 18 months, he didn't say anything, but I knew what he was thinking. In his world, 18 months just isn't long enough to feel entitled to a promotion. Promotion is primarily seniority-based, and the company rewarded loyalty as much as, err, value creation. It's a different world we're in, but I'm not sure exactly what makes it different: is it the 21st century, something fundamental about the industry, or the fact that software people feel they have more mobility, and thus less loyalty and patience?
One thing I'm fairly certain about is that companies don't treat us worse than they treated blue collar workers in the 70s. I think we'd all be surprised by the poor selection of candy in the catered employee cafeteria they had over at the shipping depot.
There are a lot of factors for the change in loyalty but I think the single biggest one is from when the managerial class went all-in on outsourcing. Those execs didn't care that they had a factory full of workers that had been loyal for decades, they happily sent those job oversees for a bump in that year's profit (and the resulting bonus). The people making those decisions didn't care that so many families, towns and cities were ruined by these actions, through no fault of the workers.
Given that betrayal of the old social contract, why on earth would anyone choose to be loyal to such companies? Work loyalty still exists with individual managers or owners of small businesses that actually interact with their workers, but these days most workers correctly assume that most corporations are being run with little regard to anything aside from profit; and those workers act accordingly.
Loyalty died because the C-suite are comically greedy idiots and don't care to keep the good workers by recognizing their worth. Mind you, they never really did, but people just realize it a bit more now, plus things have gotten worse in that regard.
I can't tell you the amount of good colleagues I've seen leave because management was too stubborn to give them a 7% raise. The most baffling thing is that they'll have no qualms (or perhaps no choice) to subsequently replace them with someone else for at minimum double of whatever 7% would've cost them. This causes a cascading issue where people are annoyed that new hires get such a big boost while the current staff have to fight for every measly percentage increase, so the older employees slowly trickle out.
I've had it happen myself too. A place I really enjoyed working at, I found the work great and had a great relationship... But the CTO stubbornly refused to give me a 9% raise. I referred my friend and started looking elsewhere. I got a roughly 30% paybump, and my friend got hired to replace me for roughly 20% more than what I asked for.
So why on earth would I be loyal? The people running the show are hilariously short-sighted and can only see the beacon emanating from their VC buddies shoveling money their way, so whatever, I don't care ultimately if something I worked on dies or not.
Unions reward seniority over everything else, including skill. I'd much rather have the current environment of being able to leave for something better without starting over again at the bottom of the pile.
Incidentally, this job-hopping is bad for software, because too much institutional knowledge is getting lost, and the job-hoppers don’t get to experience the long-term consequences of their design and implementation decisions.
The thing that is different is the ridiculously high demand for developers since the 1990s, minus downturns like the dot com bust. Developers can job hop and get perks because software is still in the process of eating the world.
But no boom lasts forever. In other creative fields or games development, where supply far exceeds demand, the situation is much less favorable for workers and that's eventually where the software industry is going to be as well.
>is it the 21st century, something fundamental about the industry, or the fact that software people feel they have more mobility, and thus less loyalty and patience?
Well unions are pretty well known for prioritizing seniority above all else.
It's one of the biggest negatives that come up against them.
> Promotion is primarily seniority-based, and the company rewarded loyalty as much as, err, value creation.
Because truckers don't "create value" the same way that software engineers do. If you had a company of 100 of the "top 0.1%" truck drivers, maybe you could charge a bit more because your insurance would be lower and you'd have fewer accidents and late deliveries. If you had a company with 100 of the "top 0.1%" software engineers there's a good chance you're on your way to having a company worth billions of dollars.
You trained yourself, you paid for your schooling, you continue to learn on your own dollar for the company. The company doesn't pay for any of that anymore like back in the day, so yes, you must do what you can to keep your career flowing, jobs are just stepping stones, they aren't entitled to loyalty, because they stopped being loyal first.
> is it the 21st century, something fundamental about the industry, or the fact that software people feel they have more mobility, and thus less loyalty and patience?
I would rather phrase the question as: why should any employee have loyalty towards a given company? The main goal of companies is to make money (if they could make money without employees, well imagine that). The main goal of an employee is also to make money. People don't usually work for free (there are exceptions, of course, I'm talking here about the vast majority of works and employees). Given these statements, it's natural that:
a) companies get rid of employees that don't make money (unproductive employees). Layoffs happen every single day
b) employees switch to other companies for more money. Obviously, this is easier to do in some industries than others, but the essence is the same in all of them
> company rewarded loyalty as much as, err, value creation
Companies reward loyalty because they can keep you behind the market rates. Hiring a new person costs you market rates. Keeping you around with 2-3% increases every year with occasional promotions of 5% will ensure you stay behind the market.
I think the key is consistency, and it is consistency that is hard for a company to guarantee. If a company does not promote often, like Apple, employees will be content to stay where they are. But once the company starts to promote some people in a short time frame and especially some think the promoted do not deserve the promotion, the employees will start to envy, to demand a speedy promotion, and the company will slowly, sometimes even quickly, turn into a promotion-oriented culture. Case in point, working in Google was such a prestige 15 years ago, and few people would even think about reaching E6. What about now?
That loyalty makes zero sense when one will be downsized in 0.1 seconds if it would make the CEO 1% richer and staying in the same role means getting paid less than market rate including new folks in the same org.
As a uniom fellow he might well be overpaid if he at 30 years in makes a lot more than the 10 year guys while doing the same exact job as them.
Basically people like your dad were getting tithed by management for loyalty while wondering why you don't tithe your company for security in a market where the most important goods require 2-5x as much.
Many blue collar workers in the 70s could afford a house, a car and a wife who didn't work to take care of the home and kids.
The software engineering paradigms used within the company create brittle rube goldberg machines of events flowing everywhere in the company.
Thank you for saying this. I have interacted with various seller-facing Web software platforms (KDP, Ads, Advantage, Seller Central, Transparency, Brand Registry) for years. Hurriedly designed features, broken processes, false-positives, and kluged-together garbage are the norm. Automated support scripts, overwhelmed human CSRs, and the siloed nature of the company compound the problems.
Here's one small example: Amazon forced many sellers in the US to start selling in Brazil. It was automated. People's accounts were enabled for Brazil by default. It was poorly communicated, including no easy way to opt out (redirecting links on the help page). Many sellers in a panic started requesting support to shut down their Brazil accounts, which led to entire global accounts being shut down.
> The software engineering paradigms used within the company create brittle rube goldberg machines of events flowing everywhere in the company. Almost all of them are on maintenance mode, where the oncall burns out the engineers and prevents them from creating new products. There is no knowledge sharing between team members. Legacy team members guard their technical platform knowledge to solidify their place on the team.
I have never worked at Amazon. But I did work at a company that decided to implement microservices a la Amazon, even going so far as sharing Bezos' famous 2 pizza team memo. This effect essentially happened over night. As people spun up more and more microservices, things got more and more siloed, cross team collaboration was significantly more difficult, and things became an increasingly more complicated rube goldberg machine that just destroyed people with on call schedules.
Software engineers having "on call" schedules at all is crazy to me. You shouldn't be writing code at 3am to fix a bug after working all day just to turn around and work the next day as well.
> But I did work at a company that decided to implement microservices a la Amazon, even going so far as sharing Bezos' famous 2 pizza team memo. This effect essentially happened over night. As people spun up more and more microservices, things got more and more siloed, cross team collaboration was significantly more difficult, and things became an increasingly more complicated rube goldberg machine that just destroyed people with on call schedules.
Micro services solve a problem for companies that have already reached a certain scale were cross team communications have become unfeasible and now communicating by well defined API contract is a better choice.
Also ideally micro services should reduce the blast radius of outages. If an outage is not easily traced to what team is root causing it, then proper monitoring is not in place.
Sure I've had times where on call went off and it wasn't my team's fault but it was no more than 10 minutes to determine that and reroute the call and then to back to sleep.
The other fact is that when designing a new microservice it should be done in conjunction with the primary consumers of that service just like designing any other part of software. Stakeholders need to be brought in and consulted.
The advantage of microservices is that new code is only going to impact direct consumer s and downstream services.
It also allows you to upgrade a service in place or completely rewrite it so long as you adhere to the original contract.
I've seen impressive rollouts of security updates across a huge code base that was only possible because of a microservice-based design.
I've seen giant monoliths fall apart as multi-year long efforts are undertaken just to update the build system.
The hard part of a microservices is they require discipline in an organization and basically assigning an engineer for 1 to 2 weeks to write run books and add monitoring.
Of course, those runbooks should be written no matter what paradigm someone uses!
> The big problem is legacy employees run every part of the company
The article comes to the exact opposite conclusion.
The article repeatedly cites problems associated with culture breakdown, and tenured employees are a key source of continuity for culture. The article goes to some lengths to underline that the culture is a positive and key differentiator for Amazon.
The more interesting point is that the cultural element looks like it is highly durable and effective, but has broken down as Bezos (the most tenured employee!) has pulled back. So it's not as durable as everyone thought.
I don't think those are mutually exclusive conclusions.
Tenured employees help maintain culture, but they don't guarantee that it stays static.
Culture developed by the employees who spent their first 5 years growing with the company is not necessarily the same culture developed by those same employees who have stayed in the same role for the last 5 years with a vanishing potential for growth.
Culture is not singular, but the summation of many different desires and behaviors. The behaviors of those who climb and then defend a position is likely different from the people who change positions every few years. As time progresses, more of the defenders stay, and more of the changers leave. This would shift the culture over time, not because it’s made up of different people, but because only a subset remain.
> Almost any manager of managers has been at Amazon a long time, in that same job for a long time. There is no upward mobility at the company, unless you have been in some org 5+ years.
This is not specific to Amazon, it's endemic to the whole industry (and probably outside of the tech industry, for all I know): Very senior leaders and engineers are sometimes where they are because they've clung to their role for a long time, and they don't leave or die at a rate sufficient to frequently bubble up new senior talent through internal promotion. These people may also deserve their position because they are brilliant, too... or they may not. I've worked in a place with technical leaders where nobody knew what they did--their job was apparently "Being Employee Number 3" and nothing more.
I was at an organization that went from doing mostly smart things to doing mostly stupid things.
One of the smart things they managed to do was recognize that they were top-heavy with senior+ talent who were fixed in their thinking & behavior and aggressively began recruiting new graduates and reaching out to CS/Engineering/Science seniors. They also added some pretty impressive mentoring programs to bring the new people up to speed quickly.
Then they switched to doing stupid shit that mostly undermined all that and the newer people started leaving. But it was pretty good for a couple of years.
> I've worked in a place with technical leaders where nobody knew what they did--their job was apparently "Being Employee Number 3" and nothing more.
Why does there need to be anything more? They probably know how the systems work and are ready to step in if necessary.
Also, they busted their ass before other people were at the company, enabling the company to grow and create the jobs that all the other people are now in.
To me it's not anywhere near as egregious as the founder who worked for a couple of years, then outsourced all leadership to a CEO for hire, and now does nothing, but still maintains 50%+ ownership of a company.
> Almost any manager of managers has been at Amazon a long time, in that same job for a long time. There is no upward mobility at the company, unless you have been in some org 5+ years.
That's not true, at least not in AWS. In fact, I'd argue that a big problem in AWS is that promotion is too fast too soon. Getting to L6 used to be a big deal, and many people were content with being on L5. But now everyone expects that L5 gets promoted to L6 in 2 years or even less. And L6 to L7 in 3 years or less. What many directors do is that they place their favorite L6 to lead a project that launches a new product. If the launch is successful, the L6 will most likely be promoted. We even joked that L8 is the new L7. And of course, this creates so much anxiety to the point that more than 50% of the 1-on-1s I'm aware of involved some discussion about "moving to the next level".
This is a nice metaphor that should become widely known and discussed!
It can be applied to general management and administration was well as software engineering. Organizational procedures tend towards complexity over time: everyone is involved in 'improving' systems by creating new procedures, and soon enough a new person is needed to deal with or manage the increasingly complex procedures. This is a well known micro economic phenomenon. It's hard to simplify and streamline and so being aware of the tendency towards brittle rube goldberg machines is a useful concept indeed, should become Amazon's 17th management principle.
> There is no knowledge sharing between team members. Legacy team members guard their technical platform knowledge to solidify their place on the team.
OH MY GOD!
Thank you for saying this, this is __exactly__ what I've been experiencing. I've seen a bunch of people pursuing their personal (promo) agenda ruthlessly. Delivering on their own projects and initiatives and nothing else.
> There is no upward mobility at the company, unless you have been in some org 5+ years.
I'm sorry if I sound harsh, but if that's your take them either you haven't been paying attention or you're not in the company for that long. The whole org was designed so that all employees are ephemeral. Managers are encouraged to promote employees up and out. At each career level you're evaluated against your direct colleagues in the same level, and those lagging behind are bound for PIPs.
Check out the old fart tool. The average tenure is below 3 years. Do you it screams upward mobility?
Those are just churn and burn lower level employees. I am talking about at the L7+ level. L6 and below is almost a completely different company.
I have worked on major tier 1 services in every major part of the company: Retail, Alexa, and AWS. I know many of the people running the important orgs
Maybe that's just what happens to companies that have been around a long time. They go on maintenance mode. You don't see coke or visa innovating much either.
It seems like optimizing for innovation makes sense with new upstart products and optimizing for maintenance makes more sense with established products.
You started with if Amazon wants change and I think that's exactly what a product with a position of relative market dominance doesn't want
Smart companies (I have no idea if Amazon is "smart" or not) are always innovating. However, most of the innovation will be internal. I used to work for a large corp that owned 80% of its main market and we were always encouraged to seek new ways of doing things and to file as many patents as possible. They were smart enough to realize that they got where they were by being innovative and that no matter how much of the market they controlled, they couldn't stay there by standing still.
That would make sense, except Amazon stock's PE is currently around 50, which means that it's priced like a highly innovative company with large growth potential. So, if management doesn't want a massive stock price drop (and they obviously don't), they have to structure the company as if it's innovative and high-growth, to sell a believable story to the stock market.
>AWS hasnt released an innovative product in a really long time
They never released anything innovative, ever. Amazon creates value through optimization. The original AWS came about because they had extra servers lying around that they needed for holiday traffic, and they decided to rent those out.
The problem with Amazon is that its too bloated, which goes against their optimization bread and butter.
The cycle goes like this. First you have an entry level engineer, that hasn't been taught really how to solve problems algorithmically - instead its basically just education in the form of memorization about problems and how to solve them, without anything more fundamental.
Then, companies like Amazon need engineers to actually build the products, so they are forced to tailor the interview process to them, thus the prevalence of leetcode style questions, because they know that the engineers are studying those for other companies.
So the candiates get selected are basically those that have shown that they can memorize processes better than others. When these candidates work, they do the exact same thing internal to the company, focus on doing the existing processes in hopes to get promoted.
As a result you get lots of bloat both time and technology spaces. So no, promoting them into decision making positions is not the right thing to do.
The best thing Amazon can actually do long term is to focus on more automation, and reduce headcount. You want fewer, more talented engineers who are able to solve problems autonomously without barriers in the way, who don't need handholding or don't need to handhold others.
AWS itself was one of the biggest innovations in technology, of all time. Cloudformation, IAM policies, and creating these services as independent composable blocks was revolutionary. S3 was completely new, and is still a dominant force in cloud computing. But my point was that all of the best ideas in AWS came long ago.
There are newer companies, like temporal.io, whose platform capabilities make AWS look outdated at this point.
I think your understanding of leetcode is not correct. It filters for:
Can learn computer science concepts
Is willing to sit in front of a screen and learn said concepts for a while
Is willing to follow directions and recipes
Is willing to follow the rules
Has some minumum bar of intelligence
Unfortunately, these interviews do work. Some percentage of people that pass the interview are actually very good. The amazon firing process will weed out the rest.
Meta has released the best open source software in the last 20 years, and their hiring process is all leetcode memorization
> The original AWS came about because they had extra servers lying around that they needed for holiday traffic, and they decided to rent those out.
This isn't true, it's a bit of marketing nonsense.
There was a paper proposing to create the service, it got workshopped quite a bit, and got funded. The servers used weren't extras, it was dedicated capacity from day one.
At the time, Amazon was not using the same hardware (or anything) as AWS. Even today, there are still critical Amazon services running on the older corp fabric, because the Native AWS migration isn't 100% complete.
The other key parts of AWS were also innovation, and not mere optimization.
You have demonstrated that you have a near complete lack of understanding of how AWS innovates. Your ignorance is thorough, and that gives you confidence; but it's unwarranted. You're just another Dunning-Kruger twit.
>>Legacy team members guard their technical platform knowledge to solidify their place on the team.
This thing comes up in a lot of companies, but really the issue is your 2-year term job tourists/hoppers, and there are quite a few of you going around. Its tiring after a while to keep teaching and training every new member who joins your team. This look even more pointless when you look at the fact that they are likely to leave in a few months anyway.
You mostly have your own personal knowledge management system, where all the tribal knowledge goes. Giving people a run of such a large corpus of knowledge/information, especially when they are not like to work with your for more than a few months is pointless.
Eventually you only get as much information as much as you have commitment.
>>If Amazon wants to change they need to remove a significant amount of tenured employees, and actually promote young engineers into decision making positions.
Why would you promote short term people, who are likely to make bad decisions without stake only to fire people who have demonstrated serving in the long term interests of the company?
>>AWS hasnt released an innovative product in a really long time
The whole point of AWS is scale and stability, not newer products.
Amazon seems to have been run in non-ZIRP mode during ZIRP. This may save their asses when ZIRP is firmly over.
You say there isn't any innovation: May be you don't need that in a utility company that moves boxes and bits? You need reliable utility that customers expect and love.
In an alternate ad-supported company where the primary product (ads) is not the one people are most familiar with, you could play all these games of 'upward mobility', 'promotion' etc because money runs freely and your job is detached from the reality of product, customers or even the larger company goals (assuming, you are not directly working on ads).
However, in a company that is truly customer focused (and obsessed - to over use a Bezos word) as is Amazon: all of what you said seems like a good thing?
I do take issue with how they treat the low-level employees with ruthless nearly-dictatorial oversight - Amazon burn out is a real thing. OTOH, having talked to Amazon engineers/PMs who quit due to burnout still have some sort of Stockholm syndrome where they have fond attachment to their 'burn out' time and how boring/unfulfilling their new job at X/Y/Z is! It's Complicated.
> The software engineering paradigms used within the company create brittle rube goldberg machines of events flowing everywhere in the company. Almost all of them are on maintenance mode, where the oncall burns out the engineers and prevents them from creating new products. There is no knowledge sharing between team members. Legacy team members guard their technical platform knowledge to solidify their place on the team.
Ah, the 'ol "workforce greening" where we get rid of all the expensive old farts and replace them with younger/smarter/cheaper devs right out of school.
It's brilliant and it always works. There are no downsides whatsoever.
I've always liked the SRE approach, where you can alleviate software engineers to build new features without burdening the team with 24/7 on call duties.
SRE/Ops person here. SRE only works if SRE can look at software and go "Nope, it's not ready for production and I don't care how wanted this feature is." Almost no company is mature enough to allow that behavior.
maybe. i don't know. AWS main services is like an AK-47, it just works, with minimal maintenance. If they started "innovating" like Google with a million different products that get regularly culled, I wouldn't be a faithful user of almost two decades by now.
> Amazon wants to change they need to remove a significant amount of tenured employees, and actually promote young engineers into decision making positions
>The engineers themselves are not students of computer science, but just crunch out tickets.
What does this even mean?
Does it mean they do not have proper CS background? If it means what I think it means, how is that even possible? Amazon recruits at top tier schools, not po-dunk university. Do that have a large % of their Engineering staff from bootcamps?
Being a student not in a narrow sense of being enrolled in a school, but being someone who studies and learns new things by doing rather than simply doing the given task in a conventional/quick/easy way that may not resolve the underlying issues that caused the problems in the first place.
The article brings up the two new LPs that were added, one being "Strive to be the world's best employer".
The biggest slap in the face about this LP is that the word "strive" used to be a bad word at Amazon. If you ever said you were going to "strive" to do something, you would be told that's not good enough. If you put it in a doc, you would be told to remove it. "Strive" was a weasel word. We never accepted "striving" as part of our tenets or our goals. Our goals never were to "strive to build a good service", our goal was just "build a good service"!
And then they went and made the new LP "Strive to be the world's best employer". Why isn't it just "Be the world's best employer"?
It may seem like a small thing, but it's an example of the ethos that has been chipped away inside Amazon. That particular LP has always been the butt of jokes because it's been clear over the last 5 years that leadership isn't actually serious about it, but the use of the weasel word "strive" really just put the cherry on top.
I mean, everybody knows LPs are BS when they put "Strive to be the world's best employer". Anyone who either works/worked at Amazon or knows someone working there understand what the work culture is like there.
And of course, everybody understands there is no way you can force people back into office -- many people commute over an hour a day -- and also be "best employer" at the same time. That's just obvious.
"I predict one day Amazon will fail. Amazon will go bankrupt," Jeff Bezos.
One of the most surprising things in my brief experience at Amazon was how much of a shitshow it was. The two-pizza rule and self-sustainability for each team led to huge overlaps, with teams doing the same thing.
With such a huge organization, you had to go through 15 different stakeholders to get a single thing done, and there was an ingrained middle management whose only function was to connect you to the right person.
Just figuring out who was responsible for what and how to get things done was a challenge in itself.
Despite all this, Amazon still succeeds, and their process of PR/FAQ, leadership principles, and one-pagers is one of the best I've ever seen.
But I wonder if at some point, like with any philosophy and just like Bezos predicted, it will become too much and the whole thing will cave in on itself.
To give Amazon and Bezos credit, their 14 leadership principles give a pretty balanced framework for decision making. Customer obsession and working backwards to help focus on what's important, disagree and commit to resolve differences that root in intuition or assumptions, bias for action to minimize analysis paralysis, and etc. It's amazing that Amazon can sustain its size for so long. But yeah, eventually it is people who enforces culture, and eventually an empire falls.
The LPs are bullshit. They are basically templates that the people in power can (ab)use to force their narrative. Want others to shut up and do the job? "Disagree and Commit". Don't want to spend money on employee's well-being? "Frugality". All else? "Customer Obsession". And what does "Are Right, A Lot" even mean?
They subject us to meet with them as customers on Chime. This is despite everyone hating the product. CodeCommit was annoying because nobody uses it, and you had to touch adjacent projects like CodeStar to do something like trigger on a GitHub commit.
> With such a huge organization, you had to go through 15 different stakeholders to get a single thing done, and there was an ingrained middle management whose only function was to connect you to the right person.
If you're able to recall, can you list who these 15 stakeholders were? Are they like legal department approval, etc?
Something that seems to be implicit in modern day criticisms of Amazon is the idea that it succeeded because of its leadership principles.
I'm not saying that's not true, but we shouldn't take it at face value that Amazon's internal values drove its success. The values stuff seemed to me to be mostly propaganda when I was onboarding at Amazon.
Could it just be basic market forces that caused Amazon to grow, attracting the best talent due to high compensation, which caused a (to borrow terminology from Bezos) "virtuous cycle"?
People talk about Amazon's corporate culture in a way that I don't see them talk about Google, Facebook, Apple, or Microsoft. Which makes me inclined to believe that it's mostly hocum used to justify where they ended up, instead of just attributing it to being in the right place at the right time.
I have never seen an 18-inch Chicago style pizza (assuming you mean the thick "deep dish" kind and not the thin "tavern style" kind). I've had them in a dozen places there, but I've neither seen nor heard of one > 14 inches.
Amazon management ethos is famous. I've always wondered if it's actually effective. Traditionally, power follow these rules:
De Mesquita, B. B., Smith, A., Siverson, R. M., & Morrow, J. D. (2005). The logic of political survival. MIT press.
Which is echoed in the article:
> One current Amazon senior manager said they’ve consistently observed bosses new to the company use the principles “as weapons to put those who aren’t favorites in their place,” while employing other principles to build up their favorites.
I'd assume that the older management style that the article points out (from Bezos) was similar, but with different words; As these rules about power are consistent from governments, to companies, to home owners associations, etc. But the article paints a rosy picture of them, so it's not clear if there's something novel there, or just a dressed up version of the same old rules.
They should stop making a cargo cult of Amazon's idiosyncratic management techniques and adopt the "GE Way" that is proven to be the best way to run a company by business school professors all over the world.
Readit News
The software engineering paradigms used within the company create brittle rube goldberg machines of events flowing everywhere in the company. Almost all of them are on maintenance mode, where the oncall burns out the engineers and prevents them from creating new products. There is no knowledge sharing between team members. Legacy team members guard their technical platform knowledge to solidify their place on the team.
The engineers themselves are not students of computer science, but just crunch out tickets.
If Amazon wants to change they need to remove a significant amount of tenured employees, and actually promote young engineers into decision making positions.
AWS hasnt released an innovative product in a really long time
Sometimes I try to talk to my 83 year old dad, who was a Teamster at the same company for his entire 35 year career, about the software industry. He's so surprised how often people like me change jobs, how we switch companies as a way to get a raise, and just generally how different expectations are. When I told him about how I'd left a company partly because they didn't promote me after 18 months, he didn't say anything, but I knew what he was thinking. In his world, 18 months just isn't long enough to feel entitled to a promotion. Promotion is primarily seniority-based, and the company rewarded loyalty as much as, err, value creation. It's a different world we're in, but I'm not sure exactly what makes it different: is it the 21st century, something fundamental about the industry, or the fact that software people feel they have more mobility, and thus less loyalty and patience?
One thing I'm fairly certain about is that companies don't treat us worse than they treated blue collar workers in the 70s. I think we'd all be surprised by the poor selection of candy in the catered employee cafeteria they had over at the shipping depot.
Given that betrayal of the old social contract, why on earth would anyone choose to be loyal to such companies? Work loyalty still exists with individual managers or owners of small businesses that actually interact with their workers, but these days most workers correctly assume that most corporations are being run with little regard to anything aside from profit; and those workers act accordingly.
I can't tell you the amount of good colleagues I've seen leave because management was too stubborn to give them a 7% raise. The most baffling thing is that they'll have no qualms (or perhaps no choice) to subsequently replace them with someone else for at minimum double of whatever 7% would've cost them. This causes a cascading issue where people are annoyed that new hires get such a big boost while the current staff have to fight for every measly percentage increase, so the older employees slowly trickle out.
I've had it happen myself too. A place I really enjoyed working at, I found the work great and had a great relationship... But the CTO stubbornly refused to give me a 9% raise. I referred my friend and started looking elsewhere. I got a roughly 30% paybump, and my friend got hired to replace me for roughly 20% more than what I asked for.
So why on earth would I be loyal? The people running the show are hilariously short-sighted and can only see the beacon emanating from their VC buddies shoveling money their way, so whatever, I don't care ultimately if something I worked on dies or not.
But no boom lasts forever. In other creative fields or games development, where supply far exceeds demand, the situation is much less favorable for workers and that's eventually where the software industry is going to be as well.
Well unions are pretty well known for prioritizing seniority above all else.
It's one of the biggest negatives that come up against them.
Because truckers don't "create value" the same way that software engineers do. If you had a company of 100 of the "top 0.1%" truck drivers, maybe you could charge a bit more because your insurance would be lower and you'd have fewer accidents and late deliveries. If you had a company with 100 of the "top 0.1%" software engineers there's a good chance you're on your way to having a company worth billions of dollars.
I would rather phrase the question as: why should any employee have loyalty towards a given company? The main goal of companies is to make money (if they could make money without employees, well imagine that). The main goal of an employee is also to make money. People don't usually work for free (there are exceptions, of course, I'm talking here about the vast majority of works and employees). Given these statements, it's natural that:
a) companies get rid of employees that don't make money (unproductive employees). Layoffs happen every single day
b) employees switch to other companies for more money. Obviously, this is easier to do in some industries than others, but the essence is the same in all of them
Companies reward loyalty because they can keep you behind the market rates. Hiring a new person costs you market rates. Keeping you around with 2-3% increases every year with occasional promotions of 5% will ensure you stay behind the market.
As a uniom fellow he might well be overpaid if he at 30 years in makes a lot more than the 10 year guys while doing the same exact job as them.
Basically people like your dad were getting tithed by management for loyalty while wondering why you don't tithe your company for security in a market where the most important goods require 2-5x as much.
Many blue collar workers in the 70s could afford a house, a car and a wife who didn't work to take care of the home and kids.
look what they took from us. I've been working for 24 years and I expect I'll be working 25-30 years more.
Thank you for saying this. I have interacted with various seller-facing Web software platforms (KDP, Ads, Advantage, Seller Central, Transparency, Brand Registry) for years. Hurriedly designed features, broken processes, false-positives, and kluged-together garbage are the norm. Automated support scripts, overwhelmed human CSRs, and the siloed nature of the company compound the problems.
Here's one small example: Amazon forced many sellers in the US to start selling in Brazil. It was automated. People's accounts were enabled for Brazil by default. It was poorly communicated, including no easy way to opt out (redirecting links on the help page). Many sellers in a panic started requesting support to shut down their Brazil accounts, which led to entire global accounts being shut down.
https://sellercentral.amazon.com/seller-forums/discussions/t...
I have never worked at Amazon. But I did work at a company that decided to implement microservices a la Amazon, even going so far as sharing Bezos' famous 2 pizza team memo. This effect essentially happened over night. As people spun up more and more microservices, things got more and more siloed, cross team collaboration was significantly more difficult, and things became an increasingly more complicated rube goldberg machine that just destroyed people with on call schedules.
Micro services solve a problem for companies that have already reached a certain scale were cross team communications have become unfeasible and now communicating by well defined API contract is a better choice.
Also ideally micro services should reduce the blast radius of outages. If an outage is not easily traced to what team is root causing it, then proper monitoring is not in place.
Sure I've had times where on call went off and it wasn't my team's fault but it was no more than 10 minutes to determine that and reroute the call and then to back to sleep.
The other fact is that when designing a new microservice it should be done in conjunction with the primary consumers of that service just like designing any other part of software. Stakeholders need to be brought in and consulted.
The advantage of microservices is that new code is only going to impact direct consumer s and downstream services.
It also allows you to upgrade a service in place or completely rewrite it so long as you adhere to the original contract.
I've seen impressive rollouts of security updates across a huge code base that was only possible because of a microservice-based design.
I've seen giant monoliths fall apart as multi-year long efforts are undertaken just to update the build system.
The hard part of a microservices is they require discipline in an organization and basically assigning an engineer for 1 to 2 weeks to write run books and add monitoring.
Of course, those runbooks should be written no matter what paradigm someone uses!
The article comes to the exact opposite conclusion.
The article repeatedly cites problems associated with culture breakdown, and tenured employees are a key source of continuity for culture. The article goes to some lengths to underline that the culture is a positive and key differentiator for Amazon.
The more interesting point is that the cultural element looks like it is highly durable and effective, but has broken down as Bezos (the most tenured employee!) has pulled back. So it's not as durable as everyone thought.
Tenured employees help maintain culture, but they don't guarantee that it stays static.
Culture developed by the employees who spent their first 5 years growing with the company is not necessarily the same culture developed by those same employees who have stayed in the same role for the last 5 years with a vanishing potential for growth.
This is not specific to Amazon, it's endemic to the whole industry (and probably outside of the tech industry, for all I know): Very senior leaders and engineers are sometimes where they are because they've clung to their role for a long time, and they don't leave or die at a rate sufficient to frequently bubble up new senior talent through internal promotion. These people may also deserve their position because they are brilliant, too... or they may not. I've worked in a place with technical leaders where nobody knew what they did--their job was apparently "Being Employee Number 3" and nothing more.
One of the smart things they managed to do was recognize that they were top-heavy with senior+ talent who were fixed in their thinking & behavior and aggressively began recruiting new graduates and reaching out to CS/Engineering/Science seniors. They also added some pretty impressive mentoring programs to bring the new people up to speed quickly.
Then they switched to doing stupid shit that mostly undermined all that and the newer people started leaving. But it was pretty good for a couple of years.
Why does there need to be anything more? They probably know how the systems work and are ready to step in if necessary.
Also, they busted their ass before other people were at the company, enabling the company to grow and create the jobs that all the other people are now in.
To me it's not anywhere near as egregious as the founder who worked for a couple of years, then outsourced all leadership to a CEO for hire, and now does nothing, but still maintains 50%+ ownership of a company.
Seems like this is also the problem with Congress.
That's not true, at least not in AWS. In fact, I'd argue that a big problem in AWS is that promotion is too fast too soon. Getting to L6 used to be a big deal, and many people were content with being on L5. But now everyone expects that L5 gets promoted to L6 in 2 years or even less. And L6 to L7 in 3 years or less. What many directors do is that they place their favorite L6 to lead a project that launches a new product. If the launch is successful, the L6 will most likely be promoted. We even joked that L8 is the new L7. And of course, this creates so much anxiety to the point that more than 50% of the 1-on-1s I'm aware of involved some discussion about "moving to the next level".
This is a nice metaphor that should become widely known and discussed!
It can be applied to general management and administration was well as software engineering. Organizational procedures tend towards complexity over time: everyone is involved in 'improving' systems by creating new procedures, and soon enough a new person is needed to deal with or manage the increasingly complex procedures. This is a well known micro economic phenomenon. It's hard to simplify and streamline and so being aware of the tendency towards brittle rube goldberg machines is a useful concept indeed, should become Amazon's 17th management principle.
OH MY GOD!
Thank you for saying this, this is __exactly__ what I've been experiencing. I've seen a bunch of people pursuing their personal (promo) agenda ruthlessly. Delivering on their own projects and initiatives and nothing else.
Hire and develop the best my hairy ass!
Deleted Comment
I'm sorry if I sound harsh, but if that's your take them either you haven't been paying attention or you're not in the company for that long. The whole org was designed so that all employees are ephemeral. Managers are encouraged to promote employees up and out. At each career level you're evaluated against your direct colleagues in the same level, and those lagging behind are bound for PIPs.
Check out the old fart tool. The average tenure is below 3 years. Do you it screams upward mobility?
I have worked on major tier 1 services in every major part of the company: Retail, Alexa, and AWS. I know many of the people running the important orgs
It seems like optimizing for innovation makes sense with new upstart products and optimizing for maintenance makes more sense with established products.
You started with if Amazon wants change and I think that's exactly what a product with a position of relative market dominance doesn't want
Both exist in industries that aren’t innovating much. Amazon doesn’t enjoy such a luxury.
That... seems about right? I wouldn't expect to get to L7+ in much less than that.
Firstly:
>AWS hasnt released an innovative product in a really long time
They never released anything innovative, ever. Amazon creates value through optimization. The original AWS came about because they had extra servers lying around that they needed for holiday traffic, and they decided to rent those out.
The problem with Amazon is that its too bloated, which goes against their optimization bread and butter.
The cycle goes like this. First you have an entry level engineer, that hasn't been taught really how to solve problems algorithmically - instead its basically just education in the form of memorization about problems and how to solve them, without anything more fundamental.
Then, companies like Amazon need engineers to actually build the products, so they are forced to tailor the interview process to them, thus the prevalence of leetcode style questions, because they know that the engineers are studying those for other companies.
So the candiates get selected are basically those that have shown that they can memorize processes better than others. When these candidates work, they do the exact same thing internal to the company, focus on doing the existing processes in hopes to get promoted.
As a result you get lots of bloat both time and technology spaces. So no, promoting them into decision making positions is not the right thing to do.
The best thing Amazon can actually do long term is to focus on more automation, and reduce headcount. You want fewer, more talented engineers who are able to solve problems autonomously without barriers in the way, who don't need handholding or don't need to handhold others.
There are newer companies, like temporal.io, whose platform capabilities make AWS look outdated at this point.
I think your understanding of leetcode is not correct. It filters for:
Can learn computer science concepts
Is willing to sit in front of a screen and learn said concepts for a while
Is willing to follow directions and recipes
Is willing to follow the rules
Has some minumum bar of intelligence
Unfortunately, these interviews do work. Some percentage of people that pass the interview are actually very good. The amazon firing process will weed out the rest.
Meta has released the best open source software in the last 20 years, and their hiring process is all leetcode memorization
This isn't true, it's a bit of marketing nonsense.
There was a paper proposing to create the service, it got workshopped quite a bit, and got funded. The servers used weren't extras, it was dedicated capacity from day one.
At the time, Amazon was not using the same hardware (or anything) as AWS. Even today, there are still critical Amazon services running on the older corp fabric, because the Native AWS migration isn't 100% complete.
The other key parts of AWS were also innovation, and not mere optimization.
You have demonstrated that you have a near complete lack of understanding of how AWS innovates. Your ignorance is thorough, and that gives you confidence; but it's unwarranted. You're just another Dunning-Kruger twit.
what's the evidence that it's better run? continued growth could just as likely (or more likely) be a result of its dominant position
This thing comes up in a lot of companies, but really the issue is your 2-year term job tourists/hoppers, and there are quite a few of you going around. Its tiring after a while to keep teaching and training every new member who joins your team. This look even more pointless when you look at the fact that they are likely to leave in a few months anyway.
You mostly have your own personal knowledge management system, where all the tribal knowledge goes. Giving people a run of such a large corpus of knowledge/information, especially when they are not like to work with your for more than a few months is pointless.
Eventually you only get as much information as much as you have commitment.
>>If Amazon wants to change they need to remove a significant amount of tenured employees, and actually promote young engineers into decision making positions.
Why would you promote short term people, who are likely to make bad decisions without stake only to fire people who have demonstrated serving in the long term interests of the company?
>>AWS hasnt released an innovative product in a really long time
The whole point of AWS is scale and stability, not newer products.
You say there isn't any innovation: May be you don't need that in a utility company that moves boxes and bits? You need reliable utility that customers expect and love.
In an alternate ad-supported company where the primary product (ads) is not the one people are most familiar with, you could play all these games of 'upward mobility', 'promotion' etc because money runs freely and your job is detached from the reality of product, customers or even the larger company goals (assuming, you are not directly working on ads).
However, in a company that is truly customer focused (and obsessed - to over use a Bezos word) as is Amazon: all of what you said seems like a good thing?
I do take issue with how they treat the low-level employees with ruthless nearly-dictatorial oversight - Amazon burn out is a real thing. OTOH, having talked to Amazon engineers/PMs who quit due to burnout still have some sort of Stockholm syndrome where they have fond attachment to their 'burn out' time and how boring/unfulfilling their new job at X/Y/Z is! It's Complicated.
Known feeling
> If Amazon wants to change they need to remove a significant amount of tenured employees, ...
Doesn't this include yourself as well then?
It's brilliant and it always works. There are no downsides whatsoever.
Hopefully, avoid doing a Boeing in the process.
Dead Comment
What does this even mean?
Does it mean they do not have proper CS background? If it means what I think it means, how is that even possible? Amazon recruits at top tier schools, not po-dunk university. Do that have a large % of their Engineering staff from bootcamps?
The biggest slap in the face about this LP is that the word "strive" used to be a bad word at Amazon. If you ever said you were going to "strive" to do something, you would be told that's not good enough. If you put it in a doc, you would be told to remove it. "Strive" was a weasel word. We never accepted "striving" as part of our tenets or our goals. Our goals never were to "strive to build a good service", our goal was just "build a good service"!
And then they went and made the new LP "Strive to be the world's best employer". Why isn't it just "Be the world's best employer"?
It may seem like a small thing, but it's an example of the ethos that has been chipped away inside Amazon. That particular LP has always been the butt of jokes because it's been clear over the last 5 years that leadership isn't actually serious about it, but the use of the weasel word "strive" really just put the cherry on top.
And of course, everybody understands there is no way you can force people back into office -- many people commute over an hour a day -- and also be "best employer" at the same time. That's just obvious.
One of the most surprising things in my brief experience at Amazon was how much of a shitshow it was. The two-pizza rule and self-sustainability for each team led to huge overlaps, with teams doing the same thing.
With such a huge organization, you had to go through 15 different stakeholders to get a single thing done, and there was an ingrained middle management whose only function was to connect you to the right person.
Just figuring out who was responsible for what and how to get things done was a challenge in itself.
Despite all this, Amazon still succeeds, and their process of PR/FAQ, leadership principles, and one-pagers is one of the best I've ever seen.
But I wonder if at some point, like with any philosophy and just like Bezos predicted, it will become too much and the whole thing will cave in on itself.
They had this monstrosity called Code Commit that I saw recently is getting canned. Good riddance. What an ugly pos.
This is false. Otherwise I'd be interested in any reliable sources.
As far as I can tell this is some sort of urban myth since AWS first stepped onto the scene.
If you're able to recall, can you list who these 15 stakeholders were? Are they like legal department approval, etc?
I'm not saying that's not true, but we shouldn't take it at face value that Amazon's internal values drove its success. The values stuff seemed to me to be mostly propaganda when I was onboarding at Amazon.
Could it just be basic market forces that caused Amazon to grow, attracting the best talent due to high compensation, which caused a (to borrow terminology from Bezos) "virtuous cycle"?
People talk about Amazon's corporate culture in a way that I don't see them talk about Google, Facebook, Apple, or Microsoft. Which makes me inclined to believe that it's mostly hocum used to justify where they ended up, instead of just attributing it to being in the right place at the right time.
Today I learned that teams in Amazon should contain no more than 2 people.
I guess Amazon has a problem with specifications as well.
Or just me.
The Amazon "2 pizzas" are Two Large American pizzas. Something with 8-12 slices where 2 slices is enough for a meal.
De Mesquita, B. B., Smith, A., Siverson, R. M., & Morrow, J. D. (2005). The logic of political survival. MIT press.
Which is echoed in the article:
> One current Amazon senior manager said they’ve consistently observed bosses new to the company use the principles “as weapons to put those who aren’t favorites in their place,” while employing other principles to build up their favorites.
I'd assume that the older management style that the article points out (from Bezos) was similar, but with different words; As these rules about power are consistent from governments, to companies, to home owners associations, etc. But the article paints a rosy picture of them, so it's not clear if there's something novel there, or just a dressed up version of the same old rules.