You're mistaking the role of a mature company. Unlike a startup, in a mature company there are a ton of customers relying on your product and making sure you don't f*k up their business with a mistake or careless change is much more important than building cool new stuff quickly. You don't want your bank "moving fast and breaking things". There are a whole lot of industries where stability and consistency are an order of magnitude more important than fast innovation. This may not be as sexy or fun as rapidly prototyping some MVP, but it's how a lot of important stuff that runs the world works. To this end, a large org may not be everyone's cup of tea.
Yes, there will be some waste and bureaucracy at any large org, but that's not the same as a place full of people "that are okay getting nothing useful done". If anything, it's the established boring companies that are doing something useful (even if that something is not sexy or exciting), while a lot of startups are just burning through someone else's money designing things that no one really wants or needs.
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.
I'd like to understand this. How does a legal team do a code review that ensures a code change doesn't expose the company to legal liability?
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.
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".
It's called 'reserve capacity', and some people think it is helpful
To be honest, SME remain the economic backbone of most modern countries and the size of SME still allow them to operate somewhat effectively. Most large companies are either slowly drifting to irrelevance, surviving on a steady diet of acquisitions from teams who could previously achieve things or milking a business line they established when they were smaller and somewhat nibble. Large companies successfully growing by building what you call important stuff without acquiring are the exception.
I think, perhaps, that being siloed, bureaucratic, large, profitable, and management heavy are not the best or only qualifiers of "maturity".
Startups are busy trying to build a functional house of cards.
Established businesses are trying to keep employees from knocking over that functional house of cards.
And usually also spend the next 10 years cleaning up the total mess of a house of cards from the startup phase into a more manageable and stable house of cards.
So don't break stuff. If you are google or aws then fine do what you want. There will always be another customer along soon.
but YOU are not google or aws.
The main problem is that the team has a lot of work to do. So simple tasks might take awhile if they aren't high priority. If I got significant push back, I'd talk to my manager or skip. Because doing it sooner would mean pushing back other high priority requests.
Personally, I think we all win if the people who want to move fast are in situations where they can move fast.
* you get exposed to a wider range of technology at a startup and can work on different things; that's more fun for you personally especially when you're under 30 yo and still learning the ropes; political indoctrination is mostly non-existent
* many startups at best get acquired; so all your "useful" efforts could end up in /dev/null or be completely replaced after the next VC round
* a minority of startups are doing real tech that's worth tolerating small company inconveniences; for every Imply/Rockset/Starburst there are many more companies building another web app, likely using inferior programming languages
* Big Co compensation and benefits are unbelievable for people coming from startups. Work/life balance cannot be compared too. Unlimited PTO could actually be European-style 4 weeks. I believe there were not so many posh places to work at ten years ago and so it was less realistic to join one.
* there's no question that startups and large corporations require dramatically different mindsets/habits. But you really get paid a lot to tolerate that smaller-than-a-tiny-cog feeling.