I dunno. In my experience, it depends. Like, $PREVIOUS_COMPANY was a small shop. Not many customers, not many users. Handful of customer product deployments.

I dunno. In my experience, it depends. Like, $PREVIOUS_COMPANY was a small shop. Not many customers, not many users. Handful of customer product deployments. Even so, releases/deploys were broken most of the time. First thing I did after I got responsibility was add dev/staging with an automated and clearly documented release process from PR -> Prod, including steps for QA etc. Nothing stupidly onerous. Customers complaints stopped almost overnight. People internally knew what to expect when it came to changes being released. People could see when things were released and where etc. People knew why their work might not be propagated out yet. Higher ups knew why things might take longer and why that was beneficial. We could also break down some very simple stats about how deployments/releases were going based on git tags. Applying the limitations of a process can be useful when things have been going wrong, repeatedly, in exactly the same way. However… there were absolutely cases where adding a process didn’t make sense and would have just been adding a process for adding a process sake. For example, ee didn’t need tickets for every PR. If it was a ten minute fix just do it and explain it in the PR, that’s good enough.