Exactly. When you're a $1T+ company, nothing "just takes two weeks" to implement. What if your tiny change has an unforeseen side effect that takes down a critical auth system resulting in a revenue loss of $10M/minute. Are you going to take responsibility? What are you going to write in that postmortem? What if your change infringes on someone's patent or causes some other regulatory compliance related issue and the company gets sued? Your $BIG_COMPANY is not putting this change request through ultra-scrutiny just to frustrate you.
First, the team needing to do the work has about 10X as much work waiting in their queue than they can possibly do given their staffing. So your request either has to be more important than the existing work, you need to get a VP to expedite it, or you need to wait. It's not like there's an engineer just sitting there picking his nose browsing Facebook waiting for work. And even if you just yeet them a patch, they will need to set aside engineering time to review that patch, so back of the queue it goes, too.
Second, that work needs to go through (sometimes multiple) code reviews, have unit and integration tests written, and be able to show those test passing more than once, it needs to get reviewed by legal so it doesn't expose us to legal liability, it needs to get reviewed by security so my 9 year old can't use it to get a root shell, it needs to get reviewed by privacy/data protection so we know it's not leaking some user's personal information, it needs to get a systems review so we know it won't disrupt other critical revenue-generating services. I mean, what are you expecting, just type the code in, run a few tests, any yolo it into production?? No way.
Let's also not forget the value of having a person sitting there doing just the bare minimum needed to have some familiarity with where things are and what does what... so if something does blow up (and it will), (s)he can instantly step in and take emergency measures to restore service.
It's called 'reserve capacity', and some people think it is helpful
There is no code review by legal. There is a talk, usually multiple talks, between legal representatives and the engineers + manager delivering something. It's the engineers and manager job to explain what the piece of work will do and help legal understand its implications so they can gather knowledge and come up with their assessment given their skills in Law.
I think you read it too literally, legal will review what is the impact of some changes in compliance and so on but you, as an engineer, is responsible to translate what the code/feature/system is doing to something that legal can understand and reason about, it's part of your job if you are anywhere senior+ level.
I had to interact quite a lot with legal in my past couple of jobs, it wasn't ever an issue because the legal department seemed to be staffed with smart people that would understand what I was telling them, or would ask relevant questions to clarify their understanding, it's a two-way street, not a button to push on the PR to "ask for legal review".
Our legal team has to review parts of our application to ensure we were in compliance with certain government programs such as ITAR and EAR. They don't do code level review but they do review business processes, UI's and messaging to make sure we're in compliance.
Usually it is more like "legal needs to be notified anytime third party dependencies are updated with a list of the licenses to make sure we aren't accidentally using GPL or proprietary code".
Other times legal gets involved earlier at the planning stages in case a feature or product falls under HIPAA or similar regulatory framework.
Actual code itself doesn't cross legal's desk anywhere that I know of.
The setup I saw is: there is an IP plan that documents whatever 3rd part IP you are using in your product (open-source or not). Someone has to sign-off on that plan, and sometimes developers do self-attestation that they have not deviated from it. Additionally, the binaries are scanned for certain things to avoid escapes of pre-release information, etc.
First, the team needing to do the work has about 10X as much work waiting in their queue than they can possibly do given their staffing. So your request either has to be more important than the existing work, you need to get a VP to expedite it, or you need to wait. It's not like there's an engineer just sitting there picking his nose browsing Facebook waiting for work. And even if you just yeet them a patch, they will need to set aside engineering time to review that patch, so back of the queue it goes, too.
Second, that work needs to go through (sometimes multiple) code reviews, have unit and integration tests written, and be able to show those test passing more than once, it needs to get reviewed by legal so it doesn't expose us to legal liability, it needs to get reviewed by security so my 9 year old can't use it to get a root shell, it needs to get reviewed by privacy/data protection so we know it's not leaking some user's personal information, it needs to get a systems review so we know it won't disrupt other critical revenue-generating services. I mean, what are you expecting, just type the code in, run a few tests, any yolo it into production?? No way.