Apologies, but I missed this comment.
I’ve worked in that same environment and the first step is to value stream map to process of making a change. Document the steps, the time spent actively doing each step, and the time spent waiting before the step can begin. From there, the constraints become clear and very eye opening to management. There are also coding techniques to mitigate things like waiting on a DB change. Unstable shared test environments are something else they should be educated on as a defect generator.
The quote you gave was from the Phoenix Project. “Improving daily work is more important than doing daily work.” If we aren’t improving, we are getting worse. There is no steady state.
Improving the process shouldn’t be the goal. Improving delivery should be the goal. The process will adjust to meet the need, but measure the flow of work and relentlessly reduce the waste, the wait times, and the amount of manual processes in the value stream.
Some resources I recommend:
Engineering the Digital Transformation by Gary Gruver
Accelerate by Nicole Forsgren, et al.
I’d start there and bubble up the problems. If the organizational goal is not to help the teams have an easier time delivering then the business goals will suffer.
Yes, “rocket surgery” was intentional. :)