6% per year isn’t that high for an “Up or out” culture. Seems par for the course for Goldman Sachs, McKinsey, GE and (in the past) Microsoft. I’m not saying it’s right or wrong, just that it’s par for the course for white collar work. (Overall attrition at these firms is even higher)
Internal Amazon documents shed light on how company pressures out office workers
291–300 of 385 posts
Re: Internal Amazon documents shed light on how company pressures out office workers
#292Earlier quoted context omitted.
Which ones for example?
No one publication is exhaustively tracking exec exits, but this businessinsider article gives you an idea of what's perhaps going on and why: https://archive.is/RwUZ9
> On top of that, Amazon typically doesn’t provide additional stock rewards, even when an employee is eligible for a raise, if the stock price grows to push total compensation past a position’s pay range.
Wow what??!
Re: Internal Amazon documents shed light on how company pressures out office workers
#293I had joined Amazon as my first job out of school. I was super excited and would not mind working the long hours as the project was interesting. I enjoyed working with my team and manager. Just near the end of the year, my manager quit. The new manager ran my performance review and assessed that my performance didn’t meet expectations. I was not put on PIP. Instead, there would be a development plan that I had to com…
that's very similar to my experience. i swapped managers about a year in and my second manager put me on a PIP. except that it wasn't really a PIP, it was just him saying "i'm putting you on a PIP." -- I didn't know the difference until I had left. A friend in HR told me (after I quit) that managers do this to try to get more performance out of people. If you're on a PIP, HR will be involved.
Also, the best C++ coder I know got dinged 'cause he was refactoring huge amounts of redundant code checked in by a different developer. I think he was eventually able to convince his management chain that DRY is a good thing and got back on the promotion track, but not before the other developer (who introduced a metric crap-ton of crap code) got promoted. After taking a metaphoric crap on our project, he then left for a different team. It took two years to fix the codebase.
Re: Internal Amazon documents shed light on how company pressures out office workers
#294I had joined Amazon as my first job out of school. I was super excited and would not mind working the long hours as the project was interesting. I enjoyed working with my team and manager. Just near the end of the year, my manager quit. The new manager ran my performance review and assessed that my performance didn’t meet expectations. I was not put on PIP. Instead, there would be a development plan that I had to com…
I still can't believe that Amazon measures performance by "numbers of commits" and "SLOC". Pure insanity.
it's not the only thing they measure. but if you're at the front end of a project, you often don't have other metrics (issues closed, internal customers giving you props, etc.) so the classic (and mostly flawed) measures of performance are used.
It should also surprise no-one that design documents are not considered deliverables, only code. There's no motivation to fix a crap design. You generally have to do the absolute minimum documentation your management chain will accept, then push out some code, let it fail, then redesign it in your spare time and start pushing out incremental changes as part of your bug fixing work.
I never saw anyone intentionally build crap designs / code so they could then get props for fixing the bugs they introduced, but there were several times people didn't have time to think through the problem and built crap code that led to sev 1 / sev 2 problems. People weren't trying to build crap code, it's just a side effect of being judged on how well you implement code, not on how well you design systems.
Re: Internal Amazon documents shed light on how company pressures out office workers
#295Earlier quoted context omitted.
I still can't believe that Amazon measures performance by "numbers of commits" and "SLOC". Pure insanity.
I have given this feedback for a person at Google who made fewer than five commits in a year, each with just a handful of lines. The lines were good, so it wasn't about the quality of the work.
God damn, getting paid 250k a year to write about 500 LOC. Madness.
Re: Internal Amazon documents shed light on how company pressures out office workers
#296Earlier quoted context omitted.
I still can't believe that Amazon measures performance by "numbers of commits" and "SLOC". Pure insanity.
Current engineer at Amazon. Maybe a particular bad manager is doing this, but there's no institutional mechanism where management or executives literally count people's commits. Worst case, you're on a team who's late on deadlines and you have 0 commits in the past several months. Yeah, there are going to be questions about where people's time is being spent and are those the right priorities. Aside from that, people…
um. no. or rather, yes. any manager (or co-worker) can decide to ding you based on your KLoC metrics.
Re: Internal Amazon documents shed light on how company pressures out office workers
#297Earlier quoted context omitted.
Current engineer at Amazon. Maybe a particular bad manager is doing this, but there's no institutional mechanism where management or executives literally count people's commits. Worst case, you're on a team who's late on deadlines and you have 0 commits in the past several months. Yeah, there are going to be questions about where people's time is being spent and are those the right priorities. Aside from that, people…
I had relative number of commits mentioned as part of my negative performance evaluation. I was working on a project involving a long information gathering phase and a long design process for the architecture, but that wasn't considered an excuse. It 100% depends on your manager, though. I think managers might feel forced to make a comparisons and put an otherwise acceptable engineer on the bottom of the stack. Lines…
oh man. that is the kiss of death at amazon. ALWAYS BE CODING. ALWAYS BE COMMITTING. My director told me they looked at commit cadence, KLoC and (ugh) story points retired per sprint because it was something they could measure. You can measure code that compiles vs. code that doesn't compile. Architecture docs and designs can't be automagically evaluated; there's a lot of subjective judgement as to whether or not they're useful.
It seems unlikely this is universal, but at least in my management chain, focus on code was definitely a thing.
Re: Internal Amazon documents shed light on how company pressures out office workers
#298Earlier quoted context omitted.
I have given this feedback for a person at Google who made fewer than five commits in a year, each with just a handful of lines. The lines were good, so it wasn't about the quality of the work.
God damn, getting paid 250k a year to write about 500 LOC. Madness.
If each line you commit is worth more than $500, then it's not at all madness.
Re: Internal Amazon documents shed light on how company pressures out office workers
#299They delay if money 8s received in advance for floatand pipeline funds in India.If COD they deliver quickly.But they sometimes return the stuff without delivering.Funny and cranky in India.Many stuff don't confirm to the pictures and standards mentioned.Important household stuff delivery wantonly delayed.
Re: Internal Amazon documents shed light on how company pressures out office workers
#300Earlier quoted context omitted.
But their market cap hasn’t. Odds are they won’t 5x their size in the next five years as they did in their last five.
Their retail business is still in a tiny portion of the world.
not to mention continued cloud growth, not just as a market, but the AWS share of that growing market.