If you find a problem at a process gate (quality gate), then you need to fix the process, as well as the product (Architecture plan/Code in PR/etc). Why did the

If you find a problem at a process gate (quality gate), then you need to fix the process, as well as the product (Architecture plan/Code in PR/etc). Why did the gate catch a problem? Was it lack of knowledge, failure to follow standards etc? Management has learned too much and not enough from Lean Manufacturing. I worked in a manufacturing plant. I know why some of these rules exist. We aren't using them correctly in software development. Quality is about improving process, not just inspection. Inspection is required, but it is treated as an input to process improvement. Are your PRs an input to process improvement, or an excuse to yell at junior devs? Management techniques in Lean Manufacturing are all about producing consistency and efficiency in human effort. Software Development is not really like this. When you understand an IT process well enough, you automate it, and the software product that performs such automation should be very consistent and efficient. We want that effort to create automation products to be more efficient and consistent. But that effort is not at all like manufacturing. It is not repeatable. If it was repeatable, someone would have written a tool for it already. And thus, if we are doing our jobs, we only have hard problems. Managing software developers is more like managing other managers than it is like managing workers on an assembly line. If you are an executive who oversees managers who are making changes to processes, you need to provide contingent guidance and goals, not dictates. Software developers are making changes to processes.