I imagine you can get an "anonymous tech industry insider" to say absolutely anything including the exact opposite statement. Another issue with the statement is the fact it is an opinion using an undefined metric.

It's also pretty standard for an engineer to say "Yeah, I could build that in a weekend" when talking about some super scaled website like twitter or facebook or whatnot.

"Bloated" isn't for engineers to decide really, we're terrible at judging efforts involved.

Both of these things can be true. There is a lag time behind hiring someone, PIPing them, and terminating them. Amazon was on a hiring spree. They are almost certainly still be bloated even after these layoffs.

Disclaimer: I work at Amazon as an SDE II on the logistics side of retail.

> This is counter to what I have heard about Amazon, which is that it is a ruthless environment where low performers are stack ranked out of the company. Does anyone have any insight?

If you have to fire the bottom x% of your team every year due to low performance, doesn't it mean that you have a constant low performing cadre? Otherwise, why would you get rid of them?

So I don't think it being "cut throat" and there are "many low performers/bloat" are at odds.

Managers at Amazon are expected to put 5 to 10% on a PIP or manage them out every review cycle.

No matter if your team is amazing or not, 5% getting cut.

Which, unfortunately, is only so much related performance. Feedback circles and cabals are a thing. Pkus some people are better at operating those cycles than others.

> Managers at Amazon are expected to put 5 to 10% on a PIP or manage them out every review cycle.

A slight correction: An organizational unit larger than a 2 pizza team -- think 50 engineers, is expected to cut 5-10%. A team within that unit may lose 0 engineers, which is how high performing teams that meet all their goals stay intact.

Fair. But every manager must be prepared to put one of their people forward, even if they ultimately don't have to in the session. The pressure is still there.

Fair: 1/25th of a pizza is gonna leave a lot of people hungry!

Amazon is notorious for practicing _forced_ attrition e.g. forcing the relative low performers out of the org (who still might be performing at expectations, onboarding, etc.).

It takes a while to stack rank people out of the company. It's not an efficient pipeline. Moreover, smart engineers know how to game the system.

So Amazon, like every other FAANG, is very bloated. I've yet to experience any sort of major layoff in the industry at large. They seem mostly isolated to these mega-corps that got PPP money, hired way too much, and are now trimming back the fat. It is sort of icing the fungibility of jobs for now but not in a way that I am at all worried about.

> They seem mostly isolated to these mega-corps that got PPP money, hired way too much, and are now trimming back the fat.

I think your general point is correct: FAANG over hired during the pandemic, but I'm not sure you understand how PPP worked or how the money was distributed. Google, Amazon, and Meta weren't the primary recipients of PPP money (they directly received 0 of it).

Their stock price increased due to both performance during the pandemic, and the general loose environment created by the Federal Reserve which probably played more of a role than PPP targeting mid-size businesses.

I also think I'm being interpreted as supporting stack ranking for some reason by some inept commenters passing by. I'm not sure how they're getting that.

How is it possible to game a system like that? I thought by design it pushes more people out than even necessarily deserve it

There's no surefire way to game the system, and I would even say there is no way to game the system at all, but you just need to understand two things:

1. Your manager is the one putting you in PIP (firing plan). If you're friends with your manager, he won't put your name, even if your performance is below the bar.

2. This is applicable in every single avenue of life, but your reputation is everything. Work hard for the first few months after joining a team and impress your leadership and your colleagues on your first few tickets, then you can dial it down and still be 100% safe and be regarded as a top tier engineer. You will be "the guy that ramped us fast and executed well" for the rest of your time in that team. If you have setbacks, you won't even need to justify yourself, they will just know that "hey if this top guy is struggling it just means it's very hard".

On the contrary, I have witnessed people being fired or looked down upon just for having a bad reputation, even when they were doing just fine or had legitimate roadblocks on some tasks. One of my good friends got fired because he was the party guy of our team, so nobody was ever taking him really seriously.

I've done the stack ranking many years in multiple companies.

I rarely have seen (1) come into play. I'm sure it happens, but there is a lot of scrutiny of the stack rank, enough where I think it would be hard to pull off. I think most friend managers would tell their friend months ahead of time -- you really need to do XYZ or things are going to be tight at review time.

(2) is very true though. Reputation and perception is super important. Although I think companies now do take a harder look at delivered impact either via KPIs or OKRs.

In my experience, most engineers are pretty good. And I've struggled to find people to put in the bottom of the stack rank, because I didn't feel that their compensation would reflect the impact they had. IMO, after having to do layoffs, it is the hardest part of the job. And it sucks because there is very little way out of it for the manager. Helping person X do better, just means that now person Y is at the bottom of the stack.

> I rarely have seen (1) come into play. I'm sure it happens, but there is a lot of scrutiny of the stack rank, enough where I think it would be hard to pull off.

In Amazon you will be PIPed (or rather put in focus, which is a first step that may lead to PIP) if you are marked as "Least effective" which is the bottom 15%.

Your manager has to demonstrate why you are "Least Effective", and they have to demonstrate why you are "Top tier". However, they don't really have to justify themselves to put you in the middle of the pack, where you will be safe from PIP.

So, for sure, you may not be ranked in the top of the team if you're buddy with your boss, which means you won't get a salary increase for example, but at least you won't be PIPed, which in the end is what I assume most people care the most about.

> I rarely have seen (1) come into play.

Worked in a company that does stack ranking. Here's how you do 1 (in the opposite sense): Give the person tough tasks, with very tight deadlines. Repeat till the employee screws up, and start building evidence for a PIP. Get others involved (customers the employee is interacting with, your own manager, etc). In most cases I've seen, if a manager is unhappy with you, the others (customers, your manager) will follow your lead to get rid of the person.

If/when the employee contests this, most HRs will pick someone from the same department to be the investigator. Since it's the same department, it means it's the same culture your manager is exhibiting. They will much more likely believe them than they will you.

Source: I got semi-fired this way. To give you an example: The investigator wanted proof for everything I was claiming in my defense. Not only that, they held it against me if I had not sent emails to my manager saying I disagreed with his behavior. Eventually, I asked the investigator: "So, did my manager show you proof for all his claims?" The investigator responded with "Good point, and once this process is over I will send him and his manager feedback on the mistakes they made." Umm - sure, but why should I be punished and not them? No answer.

I somehow stayed at the company (they made an exception for me and let me change teams) - and over years saw this process repeat over and over. When an employee is in trouble, I immediately start advising them on the steps their manager will take - it usually plays out as described above.

You can be asked to dig holes and close them up again - a completely useless work and you can be given an ever increasing quota to do it with the threat that one of the holes you dig might have your body in it (extremely stressful and ruthless).

The challenge most of the people outside of Amazon do not realize is that micro-service architecture imposes a heavy penalty on team co-ordination, esp. as the software matures. A large part of core services have been built over several years (and decades) and they have been architected to optimize for some operations at the cost of other operations. You can think of this as how you would design a DB schema. It is a trade-off between write speed, query speed and availability. Now, think about it happening at massive scale. As an engineer, you would spend a lot of time working/waiting on partner teams to prioritize your changes while under pressure to deliver. A lot of teams ended up building the pieces on their own into their own services leading to a larger maintenance and operational load.

From the outside, you are very likely to think that the team is bloated and slow-moving because you are assuming green field development. Internally, Amazon is a 25-year old legacy platform with almost no single vision across teams, tons of semi-duplicate functionality and heavy operational load. Keeping the lights on (KTLO) was a big ticket item on every annual plan I created when I was there.

I think it's actually normal for teams to have duplicate functionality. The requirements are usually never actually identical and when you try to merge them it results in services with complicated configuration that have N^2 edge cases which leads to more bugs or more complicated code. I suspect what you're describing is somewhat unavoidable, and not even a bad thing.

That being said, Google for comparison does have good code re-use for certain core resources, like spanner, cloud, tensorflow, borg, etc. If you're talking about bedrock infrastructure like that, it's quite a different picture.

I did not say it is bad. I just wanted to point out that N^2 communications are a big hit (of course we know them for long time) and people under-estimate the co-ordination effort and the fact that already running systems impose constraints that are not true for green-field efforts.

I think I am regurgitating mythical man-month here and will shut up.

> the fact that already running systems impose constraints that are not true for green-field efforts

Maybe I'm doing it wrong but I often find that doing a new greenfield project sounds easier but by the time you make deal all of the non-functional stuff (connectivity, resilience, logging, build tools, documentation etc) you might have been quicker holding your nose and bodging it in somewhere vaguely appropriate in an existing system.

There is shit-ton of work to be done :)

> micro-service architecture imposes a heavy penalty on team co-ordination

This is, by far, the hardest scaling problem in SaaS: How do we divide responsibilities amongst our (code|services|teams) efficiently?

You can only grow each so much before they become unwieldy to manage.

Divide scope too much and communication becomes complex.

Divide along the wrong abstraction and you get duplication, overlap, and confusion about what's responsible for what.

And as time passes, decisions of the past constrain and complicate your options to redesign/rearchitect/reorg today.

So it's "bad micro-service architecture imposes a heavy penalty on team co-ordination", then.

...which is a fairly obvious observation. "Bad <x> imposes a heavy penalty on team co-ordination" is generalizable.

There is no bad vs good micro-service architecture. It is just that micro-service architecture imposes a different kind of penalty on co-ordination and debugging. Instead of intra-component dependency, it moves it to inter-service dependency. Each service might look simple, but the complexity is moved to service communications. It is not that obvious, imho.

Also, what is good and bad can change over time with the business. Few judgement calls in software will last forever.

There absolutely are bad microservice architectures, that's a weird claim to make. Good microservice architectures minimize or entirely eliminate the friction around the coordination and debugging. I'm working on splitting out a monorepo as we speak and I'm determining tradeoffs we'll need to make. If I do this wrong, there will be a lot of pain around navigating between the services, but there are choices I can make now that minimize (or eliminate in some cases) that pain.

I recommend you find a way to spend time with someone who knows how to design a quality microservices architecture. It will completely change your opinion about how microservices interact and the supposed "pain" therein.

If it were so obvious, I am wondering why you need to worry about doing it wrong. You talk about trade-offs as if they are fixed in time. That is not the case at all in anything but toy systems. Maybe you need to find someone who can design a quality micro-service?

You have no idea what I do and what my competencies are, yet, you are assuming you know a lot more about system design than I do and I am missing something simple.

Here is another take from Bryan Cantrill [https://www.youtube.com/watch?v=30jNsCVLpAE&t=1413s]. Very likely, he does not know anything about services either, I guess.

Can you show me where I said "building microservices is obvious"? Or if you don't believe I said that, can you describe what you think it is I'm suggesting here? Because my intent was to say, "It is obvious that microservices can be designed well and designed poorly." In fact, if you'll observe, I removed the word "microservices" from my final statement, to demonstrate that such a statement is trivially true for any given thing.

Nowhere did I say, "It is obvious how to design a good microservice." but it seems like you're arguing against that statement, not the one I made.

And for what it's worth, I don't give a hoot who you are, who Bryan Cantrill is, or what your supposed competencies are; make your argument, don't rely on your pedigree to speak for you. That should be obvious.

I think the answer is kind of obvious, but disappointing: the way to scale is to both divide responsibility while simultaneously sharing it. The way to do this well is to work on the basics: communication, training, quality, study, operations, continuous improvement.

There is no magical model for this, no buzzword, no single practice, because different businesses and use cases need to be adapted to it. But there's 70+ years of study into methods to do this, and I believe they're taught by all the business schools. It's just nobody wants to do the work.

....On the other hand, nobody teaches MBAs how drastically different tech is than other industries, and thus how you run your "factory floor" has to be different. But the basic principles above should still be applied; they just have to be adapted to the industry and work. What one should not do is just accept things however that industry does it, because they probably aren't doing the above principles either.

I really wish more people understood this. I'm working for a company that's in the middle of a move to the cloud and it feels like no one is acknowledging the sheer level of complexity being added.

This sounds like all but two of my software jobs. The greatest challenge of being an individual contributor is being beholden to the constraints of the environment. If they tell you to dig a hole then what's what you do. If they tell you to waste all day digging into some unnecessary framework to make a single CSS change that should take 30 seconds plus a few minutes for deployment then that's what you do.

In front end development people NEED the world's largest application frameworks (sometimes plural) because they cannot figure out state management. State management is stupid simple and a solved problem, but whatever. It will still, at the job, take you all day (maybe a week) to make that 30 second change.

This is why I hate frontend so much. Frontend sits right at the uncomfortable intersection between overly complicated tech that's tough to understand, and demanding PMs and UXs who need the feature to look or behave a certain way. I initially enjoyed frontend because of the hands-on nature of it, being able to make something and then play around with it in my browser. But after the 100th time wrestling around with CSS and JS to make some minuscule style change, I just am done with it.

I super enjoy pushing innovative new front end technologies in personal projects where a 30 second fix might take as much as 5 minutes after test automation and all necessary due diligence, but at past jobs I just dig that hole they tell me to dig.

If you try to bring up that the days work could be solved in less than hour if only we didn’t make all the wrong decisions and fear the platform they will look at you like you’re retarded. I have heard this mentality expressed perfectly in the movie Edge of Tomorrow: Don’t tell anybody. Are we clear? Best case scenario you’re gonna end up in a psych ward. Worse case you’ll get dissected for study

Best argument around for doing your own startup.

Do you have any recommendations for resources/tools on state management? My background is in robotics engineering and I’m working on picking up front end so I can build end to end web apps for myself. Currently learning react with a lot of head scratching.

I wrote a thorough examination of state management with a code example. That essay is small enough to fit on two printed pages. I cannot share things I have written without breaking the anonymity of this account.

Here is the summary:

* You need a storage location

* You need a defined data structure to store your state data. I recommend storing everything in a single logical storage object, because 1 is simple and simple is good.

* You will need to update and save your storage object at the needs of your application. I do it on each user interaction, because this is cheap.

* On page load you will need to access your storage object and apply it to the user facing event handlers that create your state artifacts that otherwise normally execute in response to user interactions.

That’s it. Consider the problem from the goal and work backwards to the solution.

That’s helpful. Thank you for taking the time to summarize your essay and sharing it here.

If you're building web apps for yourself, do you even need to do state management? Just print the results wrapped in HTML from your backend.

I’m hoping to grow side projects that I enjoy working on but not in the short term, hence current focus is to only build things for myself. It’s also fun and educational for me to develop my own toolbox to get a sense for what works at different scales, how to iterate quickly on features of arbitrary complexity in the same spirit as PG’s beating the averages essay.

It's not necessarily individuals. From what I saw years ago there are tons of project kicked off to see if they pan out but are probably not going to succeed. The company has some core teams around retails, mobile and AWS that do the majority of the table stakes work. The rest is a lot of team doing things that may or may not have any value. My pessimistic view is that required teams are like 10% of the company leaving 90% of maybe useful. That isn't to say the 90% should be let go. If they did you'd see no growth but it's unclear how much of it is actually useful. In good times that's fine, in rougher time they have to reduce that extra a bit.

It's because it does not talk about employee bloat, but rather product bloat.

There are a lot of teams working on either useless or _duplicate_ products.

Amazon is a place where it is frequent to discover that an another team is doing pretty much exactly the same thing as you, despite both teams existing for years.

And then there are a lot of teams working on products that do not and will never bring revenue, such as a big part of Alexa.

Another way to be "bloated" is to have a lot of teams working very hard on systems/projects that don't add value to the overall business. Those teams will still manage out their low-performers and run a ruthless environment, but the folks that remain continue to work hard without providing value. Add new systems/projects underneath because people want more scope and responsibility, repeat through a few cycles, and you arrive at the quoted line.

The biggest bloat I've found in big companies is duplicate teams. You have one problem needing to be solved and a couple VP's running a program trying to make it happen under their domain.

I generally see this play out as, one team trying to tackle the problem with a prototype and demonstration of tech. The other team just acquires as many people as possible and writes a bunch of documents. Then it gets run up the flag pole and the solution seems to be to go with the team that already has all the people.

I used to see this occasionally and always see it as wasteful. However, there is another angle here. Imagine your a C-Suite or senior level manager and you have lots of resources at your disposal. Now you have identified a strategic widget you need to get to within some timeframe, say 2 years to lay into your grand strategic vision.

Scenario A: Task a single team, staff them and let them do their thing. Cross your finger and hope they get it done.

Scenario B: Look across offices, org groups, whatever, and task 2-3 (sometimes more) teams with your task. Let them start work on it and get regular demos and updates. Eventually, pick a winner.

B looks very wasteful from the outside, until you realize that many software projects fail (like 50%). So more attempts give you a higher chance of success. Downside: Internal politics, waste, attrition from engineers throwing away code/busy work.

A is great if you can do it, but you're putting all your eggs in one basket.

A lot of times this is just bad org/bureaucracy though, but it can be done to great effect.

Disclaimer: Worked for a CEO with a large outsourced engineering base and several offices. Would see multiple attempts at different offices all the time. Eventually, grudgingly acknowledged there was a method to that madness. Trump also is famous for this (although his seemed more madness).

Scenario B very rarely happens.

What actually happens is Scenario C - it doesn't arise from a top-down planner mandating it, it arises from middle managers (or their subordinates) further down the food chain each trying to grow their own kingdom, who all get the same idea at roughly the same time, and each build their own solution to the same problem.

During times of plenty, or if the top-level planner is only absent-mindedly managing that part of their org, the firm will be willing to tolerate these competing implementations, but during lean times, they cut, cut and cut and consolidate down to one winning solution.

A lot of corporate politics and strategy makes a lot more sense when you start looking at the personal motivations of the participants in it.

Agreed, C is also a very real possibility.

Context: I recently left Amazon

Some orgs within the company are fairly lean, some are hugely bloated. Amazon isn't homogeneous. For example, Alexa is very over-resourced and it's common to hear about 4+ teams working on slight variations of the same project. Lots of redundancy there. I believe Alexa as an org is losing $5b+ per year. Contrast that to all the criticism Facebook is receiving for their investment into VR/AR. The investment in Alexa was a platform play. Amazon thought that voice would be the next big platform. I'm not sure results and trajectory justify the investment anymore.

The fact that organizations have multiple teams working on overlapping or even similar things baffles me. I can't imagine how that wouldn't be immensely dissatisfying for the individual.

Internally it was sold as: working together with other teams is too inefficient due to dependencies and differing priorities. It's faster to build it again independently than integrate with the existing service.

Not all teams are created equal. Having multiple teams with an extremely similar charter promotes competition, harder work, and deeper search for synergies elsewhere. A single team with a guarded remit is not going to try as hard and they may outright fail on their mission even if they do have internal competition.

It makes a lot of sense if you can afford it.

In environments where missing deadlines can have huge cascading effects it isn't unheard of to do redundant work so that you have a better shot of meeting your deadline and in a good case you have multiple successful options to pick from. When your deadlines are potentially expensive enough (think capital investment that need to be bought in time to be built out before old ones become uneconomical to operate) this approach can be well worth it.

This approach was made popular by Steve Jobs at Apple. He would have multiple teams competing to who's solution would survive, while the other teams products were thrown away

This goes all the way back to his early days (I think I remember a scene about this in The Pirates of Silicon Valley), but also reportedly multiple teams were building very different original iPhones

I think this approach makes sense for hardware but not pure software.

I think its easier to adjust pure software iteratively than hardware. So with hardware, it makes sense to have different teams working on similar but different things because variations of ideas need to be fleshed (and thoughts that spawn off those ideas) and it can be hard for one team to do this iteratively.

If you're right and this is where it came from, I think largely pure software teams doing this are wasting resources, but if its hardware I don't agree its wasteful

It was way before Jobs, IBM was using it ages ago.

Isn't this part of the premise of the book Hackers? Haven't read it in like 25 years, but that's what I vaguely remember.

I don't recall this coming up in Hackers: Heroes of the Computer Revolution, but it was definitely in The Soul of A New Machine, the story about Data General trying to build their first 32-bit computer.

Thank you... it was Soul of a New Machine. I don't think I even ever read Hackers!

Jobs gets credit for everything in computing the way Churchill gets credit for all the good quotes.

I think it was Mark Twain who said, “Hey, Churchill didn’t say that; that was me.”

Well played, Abraham Lincoln!

You spawn multiple teams working on very similar projects without them knowing about each other, let them grow for a while, then choose the most promising one (or with the highest traction) as your default solution and kill off the rest. Pretty normal exploration strategy.

Amazon has about 75,000 engineers. That's the equivalent of a large town. It's completely reasonable that many people would end up duplicating the work of other teams simply because they never communicate with them.

The philosophy is "1 > 2 > 0". This means ideally you'd prefer a single thing but single things often bottleneck delivery from different orgs as they have differing requirements. In that case you'll accept overlap/duplication if it keeps those orgs decoupled and both delivering faster.

I ran into this a couple years ago with partially duplicating a service that existed under another SVP org. It didn't feel good at the time but in hindsight it was probably less effort and higher chance of success than trying to align priorities across SVP orgs and making their thing work for our slightly different use cases.

Speculative execution .... which ever team moves fast wins ... heck sometimes its not even the team with the best features that wins ... teams with just enough features but who can move fast win sometimes and its bad for the long run. Most big companies have been doing this for a long time now.

Unlike Facebook Alexa was somewhat successful. See Alexa microwaves, cars, TVs, etc.. It looks like Amazon also knows when to move on vs. Meta.

Success is relative. Voice didn't turn out to be "the next big computing platform". It's still mostly a command interface. Perhaps it still could become something bigger. Alexa isn't widely used on the iPhone/iOS/CarPlay or Android/Android Auto, the two most important places for voice. Alexa works well but doesn't have a clear technology advantage vs Google Assistant (admittedly, Siri is trash).

Contrast that to VR, which is in a much earlier stage of its technology and adoption cycle: Meta has a strong technology advantage, currently has the best overall platform and _if_ VR becomes the next big computing platform, Meta is in a strong position to capture a significant proportion of market share. It's a big if! but at least there's still a chance.

Voice still has a lot of potential, especially with the advances in AI that we've been seeing recently. A robust voice-controlled interface would be immensely useful to consumers. I think the investment in Alexa voice is well worth it compared to whatever meta is doing atm.

Voice as an interface sucks for almost everything where choices exist. As a purely serial communications method you are forced to wait for enumerated choices.

As a primary interface voice was very widely used in the 80s and 90s in the form of IVRs and the industry was immediately destroyed by web browsers as fast as was possible. Nothing makes people angrier than having to go through a phone menu system and that’s just an organized version of your more general voice interface.

“Alexa set a timer” defines the kinds of interactions that are sensible to do with voice and it is very, very narrow.

It was never, ever going to be big.

From what I heard, and this was years ago, it is a very resource intensive service to actually run. Given how little I have personally used my Alexa to make or inform actual purchases, I suspect it unfortunately doesnt actually earn much.

Alexa is crazy. Close to 10K employees for a product that they don't even know how to monetize. I understand that it's part of the Amazon flywheel but there's a limit of how much you can rely on AWS to fund you.

Alexa is full of horrible managers that only care about growing their teams so that they can get a promo.

> Close to 10K employees for a product that they don't even know how to monetize.

Or work consistently.

"Alexa play music".. Nothing... Do it a few times and it finally does play music? I could have gotten up and done it myself easier/faster at times.

the links and offering is solid. I have spotify connected to my amazon account and this is NICE..but as i said, the inconsistency is frustrating.

Alexa is funded by retail’s profits.

Retail has no profits. AWS is the profit center.

and advertising

Retail has no profit after all expenses. One of those expenses is Alexa

What needs to be distinguished here is retail as in Amazon procuring and selling goods, or retail as in Amazon being a platform and another version of Aliexpress.

The former is a low single digit profit margin business, the latter probably has a decent profit margin.

Alexa does seem like it has fantastic potential. To throw so many resources at it with so little result seems like an incredibly massive failure of management.

I think Siri and Alexa are simply at the end of their roads. To move Siri and Alexa ahead, we'd need a general AI so powerful, it would change the whole world.

I wonder if, within my lifetime, it will be possible to tell a digital assistant to "order all the ingredients I need to bake the cinnamon buns as detailed in the cinnamon bun baking video I watched last month with the Chinese lady that doesn't have an accent"?

Based on the capability of state of the art language models, we may get that soon. The technology largely exists, but the compute is still too expensive. Rumor has it that GTP-4 will be able to pass for human-like.

Right, the missing step to make these assistants actually-useful beyond very simple tasks like "play [album name]" or "set a timer for 5 minutes"—which are basically just a voice-driven command line—has almost nothing to do with voice recognition per se and is more-or-less identical to the problem of "invent AGI".

It'll be useful when you can have it create, say, a menu and shopping list for your week, interact conversationally to tweak it including understanding that something like "I'm allergic to that ingredient" means never ever try to include it again while other statements of preference may be much softer, learn your preferences so those conversations get shorter every week, and order the ingredients for you, too. It barely matters if that happens over keyboard input or voice, because the hard parts of that problem have nothing to do with how the input is done.

even a "voice-driven command line" would still be pretty useful if it actually worked reliably. Google's implementation misinterprets my parents' address about 50% of the time, choosing some town I've never visited in another state as the most likely alternative. I navigate to that address at least once a month, and I even have it as a saved place in maps.

The voice recognition (given decent hardware and a fairly vanilla accent) is quite good. The problem is being able to integrate, present options, learn preferences, etc. even to the degree of that subpar assistant who you only keep paying because they're the daughter of your mother's best friend.

You want to be able to give a few parameters for a trip you're taking and get some choices back. But, as you say, that's far more about "intelligence" than the type of input.

There's a The Smile song called "You'll Never Work in Television Again." Last week I said "play <name of song>" and Alexa responded that it could not find a playback method called "television." I tried to annunciate more clearly and it replied "OK, playing <song name> on repeat," because the song title ended with the word "again."

Nothing reminds you about the difficulty in cleanly parsing human language more than trying to work through a voice interface. I'm not sure what is missing precisely, but I'd say "an ability to use semantic understanding" might be helpful. All of our AI works explicitly with no understanding of semantics, but it's becoming clear to me that the ceiling that places on their "intelligence" puts them still leagues away from the world of true AGI.

If there was also a screen, so many more things could be done. For example it could show that list of ingredients and their prices, for your approval. Then let’s say you could interact with that screen by voice (your fingers are sticky because you’re cooking now) or touch.

There is one in Amazon Echo Show. I've never used one though so I don't know how useful it is in practice. The thing is though that I'm never far from a computer in my house so I'm going to one of those for anything remotely complex.

Alexa was Jeff’s pet project. Management failure, indeed.

Failure for whom? The shareholders, sure. But Alexa is pretty cool. It is the first voice interaction that I have used that actually works. So good for Jeff.

> don't even know how to monetize

Amazon music subscriptions are $15.99/month. Doesn't that count? Sure, you can buy that without an Alexa, but that is the whole reason people do.

> Amazon thought that voice would be the next big platform

It turns out that there are many interaction models where Voice is clearly inferior. Visual discovery (contrast with music) such as for videos, as well as navigation in a UI, are poorly done via voice.

I have an Echo and a Homepod and I rarely use the Echo anymore because of their "by the way, did you know..." responses. They know there are a lot of users who want to disable that but unfortunately their goals aren't aligned with their users' goals.

Everything I use Alexa for:

"Alexa, set a timer for x mins / wake me up at x time."

"Alexa, what's the weather today?"

"Alexa, can dogs eat <type of food>?"

"Alexa, play <the song I just referenced so my wife knows the reference even though she doesn't care>"

Mostly just the first two. I don't care about anything else they try to push on me.

I got rid of my Echo mostly because of those types of responses. And also for how easy they make it for you to buy something accidentally off Amazon, or accidentally upgrade to Music Unlimited.

You can say "Alexa, stop by the way" and it will disable it for a time, but it will come back. If you really want to disable it for good, you can set up a routine to effectively issue this "snooze" on by the way at some interval.

This is what happens when you optimize for a certain metric only. Yeah you might have someone's who's writing tons of high quality code, but if this code is just a duplication of another project or there is no business use for it, then it you probably would have been better off not writing it in the first place.

People talk about food waste, but how much code is wasted?

I haven't worked at Amazon, but my experience with the world of "pip" culture is that it only really appears when value is difficult to define, which is strong evidence of bloat.

Every time you hear a story of someone at Amazon being pip'd it always comes as a surprise to the IC and, most importantly, they don't know how to avoid it.

This doesn't happen in a world where creating value is well defined. For example in the sales world nobody is confused about their performance. Sure there may be unfair reasons for having a poor sales cycle, but the sales person has zero problem identifying how they can create more value to the company: close more deals.

But I see lots of comments, both in person and online, of Amazon employees fearing a pip and not knowing the right way to keep their manager happy. This, at least to me, is evidence of the bloat. The high pressure ironically comes from the fact that nobody knows how to create real value, so they are stressed out trying to figure out how the game works.

You cannot put a dollar value to every bit of work that happens in a company.

What is the value of managers? What is the value of research? What is the value of procurement/ hr? What is the value of IT and internal support tools?

None of these individually provide value, but remove one and the company will collapse.

Ruthless environments where low performers are stack ranked out of the company creates a psychologically unsafe working environment that encourages toxic competition and makes it hard to retain your best people. I got out a long time ago, but Amazon struggled to retain their best employees because they'd go somewhere else. Amazon had such absurd turn over that they are running out of people to interview. It's a wood chipper, designed to burn out young, insecure engineers while extracting two years of boilerplate from them.

This is absurd. As an Amazonian for eight years I can say it would be absurd to do this. First, hiring someone is a lot of work. Second, we don't get much value from people the first six months anyway. We don't hire people to do boilerplate. We hire people who want to obsess over their customers.

> We hire people who want to obsess over their customers.

:eyeroll:

This reads like PR fluff and flies against the experiences shared by a lot of employees, current and former. Amazon is a huge company with a lot of variation between teams so I'm sure it's not a meat grinder for everyone, but they don't have this reputation for no reason.

Done much crying at your desk recently?

My boss at Amazon told me he was happy that his baby was born prematurely, because it meant he could be back at work in time for a launch.

> We hire people who want to obsess over their customers.

I keep hearing this, but as a customer, I don't see it.

Amazon retail experience is poor.

The layout of the site sucks (so many clicks just to see all the reviews).

They used to allow comments to reviews, which often were very useful (e.g. top review complaining about something not working, and the comments explain how to fix it). But reviewers weren't notified of the comments so they couldn't engage. And to top it all of, they recently removed all the comments.

The reviews have been gamed, not very useful.

They still let people make product pages with very different products as "formats", and that skews the reviews the wrong way.

Lots of counterfeit product issues. Perhaps more common: Problems with comingling items. I know it doesn't happen often, but being burned once is bad enough. I recently bought a toy for my daughter's birthday. The box had creases. Upon opening it was clear this was a used item. Some of the items were out of their (sealed) packaging. Perhaps my mistake for not examining it before, but whenever I buy from Walmart or Target, I don't even have to think this will be a problem. Fixing it up with a great return policy is not a solution. Oh, and I couldn't return it. They recently made it hard to contact a human, and the automated return system on their web site wouldn't let me return if I had used it. I had to open it as we couldn't change her birth date.

The search sucks. Way too many results that have nothing to do with what I searched. eBay, of all sites, is way better in this regard.

I've also been an Amazon seller (FBA). The seller portal was crap.

> Amazon had such absurd turn over that they are running out of people to interview. It's a wood chipper, designed to burn out young, insecure engineers while extracting two years of boilerplate from them.

I thought those news articles were about warehouse workers, not IT workers.

It's also true of their engineering - they have a terrible reputation which caused them to raise salaries a ton in the last 2 years just to try to get comparable engineers.

They easily pay 30% more for the same engineer just because of their culture/reputation.

I've heard about stack ranking at Amazon, but I've not seen it. Maybe it's because I work for AWS, and I'm not an SDE. But I've worked in three separate organizations within AWS, each of which have different cultures. And I have never seen any of the horror stories commonly attributed to Amazon corporate in my time at Amazon.

There are absolutely quotas for every org over a certain size. If you’re not a manager and not on the chopping block, it would be hard to notice.

+1. I’ve been here almost 6 years and across 3 different teams. Never seen any of the horrors.

If only 0.1% of Amazon employees are very unhappy and vent their horror stories online, you will hear hundreds of bad stories. If 99.9 are "just fine" with it, you won't hear a single story...

Oh my friend, there is a tool called Lift used in OLR/Talent Review by every single 50+ group at Amazon that quite literally will show your face up on a screen for everyone at the OLR meeting to discuss and rank vs your peers. If they don't have the Least Effective quota hit they will go through each face near the bottom to figure out who needs to be added. The most liberal definition possible of not stack ranking.

The simple reason why most don't notice it is people really intuitively overestimate how big 6% feels, especially when a good chunk of the people who leave and satisfy the unregretted attrition quota look just like someone leaving to another company but who were in focus or pivot when they left.

To refresh the exact rules for those not in the know:

  - Amazon requires 6% of employees who leave the company every year to be unregretted attrition aka URA

  - To be marked as URA an employee must be in Focus aka Devlist aka Devplan when they leave

  - Talent Review aka OLR must occur at least every 6 months for each leader with >=50 employees under him

    - Every employee is ranked from Least Effective - High Value 1-3 - Top Tier with quotas being 5:35:25:15:20 % respectively 

    - The 5% rated LE must be entered into Focus

    - This effectively results in 10% of employees in Focus per year 

  - Around half fail improvement plans in Focus and are presented with Pivot, which 90% results in firing. This is the oft discussed "Pip"

  - Rest either get out of Focus or leave themselves while on Focus and are still marked URA

One of the advantages of Amazon's notoriety is you can know exactly how the process works. At other FAANGS it remains more nebulous and obfuscated to my knowledge. There still is not a concrete answer on who will actually get fired under Google's new GRAD system, and Meta does not seem particularly consistent with how they target double rated meets most. I understand the least about Microsoft and Apple, despite working there.

Just because employees are ruthlessly stack ranked doesn’t mean they are working on impactful projects. Directors and especially VPs have a ton of autonomy on what their orgs pursue and are in the dark on some areas of their org, which further provides frontline and middle managers a lot of authority and it’s up to them to report up stacking within their remit and defend the positioning. So while stack ranking decisions are made, it’s not always “fair” and varies greatly across orgs. All managers regardless of level are fallible and do not always make perfect decisions on what to pursue so that adds another layer to effectiveness of employees even if they are doing the best they can at what they have been given. Cuts are at the org level based on value to the business.

Low performance can be gauged in many ways and what is a high performer in the context of a team or org may be a low performer if taking value to the overall business into account. Headcount allocations do not always reflect value (and that value varies greatly when comparing short term to long term).

In eight years at Amazon (in the supply chain org as SDE and SDM) I have not encountered anything close to "ruthless". It is true that there is rough stack ranking, but only in large organizations where it is statistically meaningful.

I forgot to screenshot the post. But I saw a post on Blind, from a BBC user (which could or could not be a reporter) asking for people to tell stories about the layoffs. I was blown away. I always assumed reporters will try to find someone and talk to them face to face (via zoom or in person) to gather intel on news stories.

What makes you think that isn't step two? Step one is finding the people and their stories then following up with the most promising/compelling ones.

Sure, there is plenty of ways to get someone from that company's attention, Looking for trolls in Blind is not the best way really, anyone can say anything their one, and the reporter would have no way of verifying it, then will publish something that is false, which we all know have happened many times. But if you think BBC is a extremely reliable source, then, yeah, you are right.

A reported doesn't need to even know who they're talking to in order to get leads on who should be pursued, but being wrong can lead to a lot of wasted hours.

If the stack ranking works then yeah they would have no bloat, but teams are just trying to demonstrate their value to someone above them who is trying to assess their value while demonstrating their own. How valuable they actually are is pretty difficult to assess. There are probably many teams sucking up millions that have a net negative impact with their contributions but how do you measure that.

Amazon got that reputation a decade ago when they were vigorously growing in user base and revenue. They couldn't hire fast enough if they even wanted to without wrecking the organization, so there was a ton of teams/people that felt immense pressure.

These days things have leveled out a little bit and I think of Amazon as a new IBM in the making. More corporate, more cruft, more politicking. This is especially true on the retail side, as Amazon has become so complicated and specialized that you'll have specific tech teams for handling edge cases for particular types of products. I think I recall there basically being a 'shoes' team that would implement features just for selling shoes on the site, etc.

I will say though that when I was in AWS a few years ago, that I was downright shocked at how lean some of the teams were. IIRC there were less than 100 developers that maintain all of dynamodb for instance.

For fun, there are currently precisely 312 employees under DynamoDB directors/VPs that are categorized at "Software Development".

Including systems engineers ups it to 348.

Do you realize how big and profitable DynamoDB is? How much data they manage?

Also DynamoDB is indeed amazing. If your usecase matches the featureset of dynamodb, it works like a charm.

This is totally true, I worked at Amazon when it first launched Kindle. There were multiple software engineers 100% dedicated to ‘making the Kindle product page work’ at this time.

Easy answer: Management is very bloated but immune, code monkey scum get the wrath of PIP.

Exactly ... In modern big software orgs it does not even matter if you are delivering value/ All that matters is Perception, Image and Exposure (PIE). Product quality, features, technical depth none of that matters, as long as you can manage your PIE.

Managers are heavily expected to keep growing their team(s). A manager whose team is flat in terms of size and scope year over year is going to be viewed as underperforming, even if they dramatically improved what they do own (in most of the company, at least).

This means a lot of managers hire for the sake of hiring, and create projects to facilitate that hiring rather than because the projects add any real value. They'll work with their PMs to invent some numbers to sell the project to leadership, but at the end of the day a lot of what goes on there is makework, solving problems that don't exist or re-solving solved problems without improving the solution significantly.

That said, since there's so much cutthroat resource contention, plenty of extremely important/valuable projects are chronically understaffed. I'm sure there's meaningful work for most to all of the engineers currently working at Amazon, but a pretty significant chunk of them are absolutely not doing anything meaningful today.

At big companies with internal mobility, switching teams at the right time is a skill. This has positives but also the potential for bloat.