Hacker News Reader

I think the more even-handed criticism of Amazon would be this: they're a highly process driven company. Practically the definition of "process over people". There are certain types of people who thrive in that environment. The people I've seen be successful there are either people who successfully disassociate their working lives from their personal lives or who are engineers with high technical ability but lacking social skills.

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 can't help but read your first paragraph and think of the show Severance. Convert everyone to simple worker bees without any agency.

Digressing here, but...

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.

It was difficult for me to watch severance because so many of the interactions among the employees reminded me of my time Amazon. I actually cried a little bit when the boss threw a coffee cup and then blamed her report for it.

How'd you come about this understanding? Very little of what you wrote here reflects my experience there.

> Practically the definition of "process over people". There are certain types of people who thrive in that environment. The people I've seen be successful there are either people who successfully disassociate their working lives from their personal lives or who are engineers with high technical ability but lacking social skills.

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.

FYI: I think you responding to the wrong parent comment. :)

Why wouldn’t it be more important to plan out the work than to do the work? We’ve all seen the graph of how much more expensive things are to change the further down the process is.

I absolutely think you should plan out how your customer will solve their problem with your product, including concrete examples, and make sure you are always headed towards that goal. I'm very waterfally that way.

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.

I don’t work for a service team. I work in Professional Services. I was working on a project and I found a bug in one of the APIs. I reached out to the service team and they found the bug - it was a 3 line change in some front end code (long story). They put a fix in almost immediately. But as I was tracking the weeks long deployment process across regions, I came to appreciate how costly any changes are at the scale of AWS. You have to measure twice and cut once.

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.

Oh yes, the pipeline deployment process is pretty amazing. I agree, for good reason. My manager has actually recommended I look at profserv teams because of the ability to deliver results for customers.

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.

> My team spends 4 hours in sprint planning every week

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.

I’ve been working as a hands on developer [1] for over 25 years between 8 companies. I’ve worked for companies with 20 people all the way to AWS.

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.

> I don’t do whiteboard coding interviews

Like, you refuse them or the positions you apply for don't require them?

The longer version of the story:

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.

Why shouldn’t all employees of any for profit company “disassociate their professional lives from their personal lives”? I go to work to exchange labor for money to support my addiction to food and shelter.

Again, this is me speaking just my experience, and not for the company in any official capacity:

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.

Until UnRegretted Attrition (re: stack ranking) is gone, it'll always be a place to avoid. Nobody likes to work with that hanging over their head. I think this is the #1 thing that will always hurt Amazon recruiting, everyone knows about it now.

> UnRegretted Attrition

Article with links to further information on UnRegretted Attrition (URA) rate: https://archive.ph/dI92l

Counterpoint to your anecdote. I didn't find Amazon all that toxic for my first 2 years until I had a baby. First, the parental leave is significantly worse than competitors. I took 3 weeks when my son was born and another 5 to help my wife transition back to work herself (only 6 were paid by Amazon). There was a 10 week period in between leaves where I was stressed, anxious, and feeling overworked and burned out. My performance suffered. I received no extra help from my manager but also received no negative feedback during that time. Welp, came back from the 2nd half of my leave and was immediately put on a pip (technically called 'focus'). Worse, there was absolutely zero empathy from this manager during the focus.

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.

I think it’s time to fight back against the anecdotes against whatever point. There’ve just been too much bad faith and misdeeds done in service of internet misinformation.

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.

> Much less since you’re posting semi-anonymously in an Internet forum.

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

That depends on the team/org you are, if you are in some cosy team in CDO, that just maintain a couple of services that other internal services use, that aren't really that important, then of course is not toxic. Talk to the folks at EC2, VPC teams.

Im not sure people are always referring to the tech sector of Amazon when they call it toxic - unless explicitly stated as “planned attrition” etc. I’ve heard great things about AWS, for example. My opinion is people refer to the company as toxic as a whole because of how warehouse workers’ conditions are or the disruption of communities around Amazon warehouses.

Can you share a little bit about how Amazon handles on-call? Do they make their dev teams be on-call for their product areas, do they have first line responders/SRE, and things like that?

You are oncall on your team's services. No matter how old those are. The frequency depends on your team size, and the level of tickets/incidents depend on the quality of the codebase. I have seen everything from one high sev ticket every 2,3 months to constant paging (3am, etc...)

What counts as "first line" depends on your situation.

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.