As others have said, management at Amazon will only direct focus on the development of new features or new services, at the complete detriment of improving existing services, or even the overall architectural design of a particular space of the business. The definition of completing a service or feature is only that a customer is using it without complaint. Management has no interest in technical reasoning, which causes the design decisions that rest at their level to be unreasonable. This leads to a few problems:
1. Services are only ever about 50% complete. Unit tests typically exist to some degree, but integration tests, documentation, complete monitoring and operational automation are rarely done. Services typically have numerous obvious bugs, grossly bad optimization, hideous over engineering, and sometimes design issues. Because the customer cannot detect these things when the first use the service (maybe it will reflect the second time as a bug, or as slow performance later down the line, or long times to develop new features), there is no interest in fixing them.
2. The graph of service dependencies is entirely unmanaged. Any service can depend on any other service, for any reason. This results in a massive, undesigned spaghetti of a system. Something like s3 or whatever will usually be supported in some way by a spaghetti built for s3, and if s3 fails, it is usually not immediately obvious which service in the spaghetti is responsible. It makes adding something new to the overall system take a very long time.
3. Even if a customer is encountering an acute problem, and management is asking for it to be fixed, if the problem is rooted at a system level outside the boundaries of a single service, thus at the level of management, management is unable to engage with any reasoning as to how it should be solved. Only management holds the keys to assigning work (senior or principal devs hold basically zero sway) and thus management must have the technical reasoning ability to make these decisions.
4. Management will sometimes intrude in service level problems and make unreasonable decisions. Examples:
4.1 I was told python is not performant (despite my history at the company having me deploy python code to every single physical host in the fleet) and asked to research and explain why it isn't scalable and we should switch off it. I declined to work on the issue
4.2 Management had an issue raised to them where a single user had sev2ed us because they couldn't paste into a field on our service. Investigation quickly revealed the user was trying to paste text with a space into a numerical field, and the browser was preventing it. The issue already had two solutions suggested: add highlighting to invalid inputs, and strip spaces from inputs. Despite this management decided a formal review was required, where somehow we would have to dig deeper than the existing explanation and explain how this happened and what should be done.