I'm torn on this. On the one hand, I really dislike when my developers behave as if their job is done as soon as the code is written and that all that's left to do is to "throw it over the wall" to QA and Ops. But that is perhaps my more general view that developers who understand how their code actually runs and how it's tested, generally do a better job and are more valuable. On the other hand, I do feel that the notion of shift left, taken to an extreme, leads to the undervaluation of specialized QA roles. QA professionals have a specific set of skills focused on testing, finding bugs, and ensuring the usability of software. If you distribute these responsibilities among developers, who may not have the same level of expertise in testing, there's a risk that the quality of the software could decline. As other comments here have mentioned, just as DevSecOps requires developers to integrate security into the development process, shift left ends up meaning a demand for a really broad skill set from developers, including expertise in testing and quality assurance. And it's pretty difficult for professionals to maintain a high level of expertise across multiple disciplines. I mean...specialization exists for a reason; it allows professionals to hone their skills in a specific area, ultimately leading to better outcomes (hopefully? usually?). So "shift left" aims to streamline the development process and integrate quality from the start, but it can inadvertently marginalize QA expertise and overburden developers, potentially compromising quality and security. I do think management often has no idea how many different specialties and expertise there are within engineering. They often conflate it all since it's just "engineering". The amount of expertise devs are expected to know these days has gotten kind of absurd.