By not deploying code directly to the running servers he's adding bureaucratic overhead to the development process rather than getting rid of it. He's putting his people in as active gatekeepers in a way that hasn't been necessary for most web development in a long time.<p>"This way of working might still be prone to errors, but at least we are not running configuration updates or deploys against resources in production."<p>If the old method was too fast and lots of mistakes got through then the new process they chose was right for that team. However, treating config changes and deploys to production as if they're toxic in general is kind of disrespectful to the vast number of companies that deploy to prod without knocking over their own website for hours at a time.<p>On top of that, if the new process is "still error prone" then he just increased the effort required by his team and slowed the overall development of the product for nothing.