Highly motivated people who always go the extra mile get exploited and burnt out. Kind people get their kindness taken advantage of and it sours their view of the world. At least that's what I've seen from the outside.
The bigger problem I have with the company is the types of managers that environment creates. The primary function of a manager at Amazon as far as I can tell is to enforce process and the secondary function is to maximize output of the people reporting to them.
Empathy is actually a disadvantage in this type of role and it selects for all sorts of what I would consider adverse behaviors among managers. The "leadership" principals relate to actual leadership as a jellyfish relates to Smucker's. Look up Google's project oxygen findings if you want a comparison.
I personally doubt I'll ever hire someone who learned engineering management at Amazon unless they've been sufficiently detoxified in a different company.
I’ve always strived to “live in a position of f%%% you” (https://m.youtube.com/watch?v=xdfeXqHFmPI). Why would I let a company “burn me out”?
When the pay/bullshit ratio gets too low, I send my always updated resume out, review my “career document” to prepare for behavioral/informal interviews (I don’t do whiteboard coding interviews), talk to people in my network and I get another job.
Before my current job, I was a dev lead and then the de facto “cloud architect” at smaller companies. My current job is much less stressful.
[1] currently my official title is not “software developer”. But for all intents and purposes, I still develop user facing software along with a crap ton of yaml, HCL, diagrams and PowerPoint slides.
Like, you refuse them or the positions you apply for don't require them?
I stayed at one company too long from the time I was 25 until I was 34. By the time I left, I was very much an “expert beginner” - I was doing old school VB6 in 2008 (discontinued in 2001) and C++/MFC/COM programming (ask your kids). But at 34, I had developed soft skills and knew how to talk to business people.
From 2008 - 2018, I both modernized my enterprise dev skills and learned how to solve business problems. I also got lucky and always seemed to get connected to managers, directors and CTOs who were new to their company and needed to solve business problems. Most of my “interviews” were casual semi-technical but mostly about process/development improvements even as I stayed hands on.
By 2016, I belatedly discovered “the cloud” when the company I worked for as dev lead wanted to “move to the cloud” and they hired “consultants” who were really just a bunch of old school Net ops folks who knew how to do “lift and shifts” duplicating and on prem architecture to AWS and of course costing more. As I learned more about AWS, I knew I could bring a unique set of talents as someone who knew both the infrastructure side and the development.
I found a job at another company where the then new CTO wanted to pivot the company to being “cloud native” and sell access to micro services to large health care companies.
I talked through my proposals after listening to him and I led the effort over the next two years.
Then at 46 a recruiter from Amazon Retail reached out to me about an SDE position. I was not interested in being a software engineer at any large company, not interested in relocating “after Covid was over”, nor was I interested in doing the leetCode/DS&A monkey dance.
She suggested I apply for a role in cloud consulting “application modernization” (really just software development + devops using cloud services) in Professional Services that was fully remote. I had the tech skills, the project leadership experience and the customer facing experience from working at small companies. My interview was all behavioral besides a little AWS techno trivia as part of the initial screening.
So in reality, I just fell into a specialty where companies are more interested in my ability to solve business problems than reversing a binary tree on the whiteboard.
That show is incredibly good. I'm not quite done with the first season (two more episodes, will likely be watching them both tonight), but it's very interesting.
I think a lot of people at first think that if they could have an operation done that makes them essentially skip their work day, they'd jump at the chance. This show really shows how there could be serious problems with that.
Capital-P-Policies get followed. But there are a lot of lower-case-p-policies, more what you might call guidelines, that are not. Sometimes, for good reasons! There are examples of things Amazon does that try to encourage individual judgement, trusting the people in place. But there are also examples where we think we know what the right process is, but for whatever reason (prioritization, we haven't figured out the right way to enforce it, scaling challenges) it's not as strictly followed as outsiders might assume.
That has been exactly my experience, after 5.5 years. My team spends 4 hours in sprint planning every week (there are 9 of us). It is way more important to try to plan out work than it is to actually do the work.
> The bigger problem I have with the company is the types of managers that environment creates. The primary function of a manager at Amazon as far as I can tell is to enforce process and the secondary function is to maximize output of the people reporting to them.
I did burn myself out trying to reduce operational load. I wasn't arguing for it the right way, so I ended up doing it myself. I was able to measure my results, but it didn't even count towards a promo because I didn't "harmonize discordant views"... instead I just did what needed to be done.
Many many folks inside Amazon say it has a startup culture. That is false. Try to find out how many of those folks have actually worked outside Amazon before taking their advice.
That seems excessive, but I don't know what area you work in. Does your team need to spend that long? I have heard of that happening within Amazon, but then people vote with their feet and move to a team that doesn't spend four hours in sprint planning.
> Many many folks inside Amazon say it has a startup culture.
I've spent roughly as much of my career at startups as I have at Amazon. It's a bit of a mix bag. Having worked at start-ups that had to spend time doing undifferentiated work (just getting automated deployments, for example), it's in some ways nice not to deal with that, and yes, you have to follow The Process for that to be easy. I sometimes see people taking chances and acting quickly on new opportunities. But yes, I also see people not taking chances when the cost of doing so would have been small. Then again, I once worked for a start-up where you had to use a particular template for a design document, and you had to produce a project plan that 6-month long projects that was accurate to the hour. So... I think it's hard to make generalizations.
In this case I'm talking about the tasks in each sprint. I think 1 day of planning per sprint is a lot. We are supposed to be agile. If we missed a task, swap it with another. If something isn't actually important, bring in something new. We end up doing this anyway... so why all the upfront planning each sprint?
Related back to the above comment, (my opinion) people really love to establish rules and processes and are not able to handle ambiguity. I spend a lot of time (remember the 4 hours a week) arguing whether a story is a mouse or a hedgehog.
IMHO it's splitting hairs, let's just do the work and we estimated a little wrong it just isn't that important.
My implementations are for a specific customer and I don’t have to worry about that type of scale where a mistake or miscommunication in requirements can be costly and affect hundreds of customers.
I have made mistakes as a contributor to a popular company sponsored open source project. Even that caused headaches beyond the scale I was use to dealing with.
When I started in AWS, I watched customers implement hack solutions for themselves because it would take our team too long to deliver a proper solution (so hard to give specifics on HN :) ). That was the hardest thing for me to handle. The mindset is what works best over the next N years, not what works best for a set of customers right now.
Honestly that is the right mindset. Early adopters know they are early adopters and will have to work around problems.
I think the take away from this conversation, for anyone still following, is that a lot of developers (like myself) want to move really really fast. AWS has processes in place to prevent this movement from breaking customers. While it is so annoying for me, it really is a win for customers.
Article with links to further information on UnRegretted Attrition (URA) rate: https://archive.ph/dI92l
Maybe Amazon can be a good place to work if you're ALWAYS able to be a solid performer but god forbid you're going through something in your personal life that temporarily impacts your ability to deliver.
As you said, your anecdote isn’t worth much. Much less since you’re posting semi-anonymously in an Internet forum.
With how job descriptions can be unilaterally rewritten by corporations at will even having a stance of remote work in a job description shouldn’t be taken as solid, unshakable truth.
Edit-trust that corporations will use you exactly as far as it benefits them and in the most exploitive nature they want.
I mean, I don't make it that hard for people to figure out who I am if that's a thing they care to do.
But I think you're right about the larger part - it's hard to trust Corporations. As I said in my case, and what I advise others to do, is rather than trusting a company (big or small), try to find individuals there you can trust (either, early in your time there, or ideally find someone that you already trust that happens to be there).
On my first team, we managed internal tools. Our customers were other people at Amazon, they submitted tickets to us directly.
For some teams at Amazon, there is at least a filter through some sort of customer support to handle certain kinds of issues. You are still on-call, but it's not like you are interacting with customers directly.
Also, since teams at Amazon tend to be small, the amount of things you are on-call for tends to be however much your team handles on its own. I know of other companies in which the oncall covers areas in other team's code bases - this is not the typical setup at Amazon.
Generally, we don't have SREs. Software engineers usually understand best how their software works, so we get faster mitigations, and they are also incentivized better to not write buggy software.
Different pockets of the company have different trade-offs and incentives. The on-call burden on some teams is higher. When I've seen this happen under good management, the managers work to do different things to relieve the burden (such as spending time working on tech debt, improving test automation, and so on).
Some of the aspects of Amazon's culture that I hear criticized often come with unfair comparisons. No one likes getting paged at 1:00 AM, and that's a thing that can happen to you at Amazon. In my personal experience though, I got paged at weird hours much more often working at start-ups. Amazon at least (again, generally, in the parts of the company I've worked) has a healthy culture around continuing to improve operations, preparing people for on-call, and to address any page events so that particular reason for getting paged doesn't happen again.
(I'm just offering my own opinion, I don't speak for Amazon in any official capacity.)