Is being slow necessarily a bad thing? Google is a large cash generating machine. Maybe making large changes quickly would be detrimental to the over all health of the company. As a counter example one might consider Musk's takeover of Twitter. Although it is still too soon to tell the effects of his "nimbleness" are not looking stellar at the moment.
Having worked in Google like companies they always seem lure talent by dangling tasty projects in front of them. But successful projects at the scale these companies need are few and far between. The talent then starts complaining the company is not nimble enough etc and moves on. One might argue this is the natural order things. One of the reason SV has so many startups. Much of what startups do is likely not that appealing to large companies and far too risky - failing at a high rate.
>But successful projects at the scale these companies need are few and far between.
Back when I was an industry analyst, I still remember a conversation I had with someone at IBM. I don't remember the context and don't quote me on the number but he said something to the effect of "If it doesn't have the potential to be at least a billion dollar business, we're not going to even try."
Basically every project consumes some slice of attention, time, and money up and down the line. You can mitigate this to some degree with decentralization but only up to a point.
At least IBM learnt that lesson. One of the most frustrating things at my previous company was the enthusiasm to throw 50+% of engineering time at projects that even in the most optimistic projections would not bring in even 1% of the profits brought in by the main product. Said main product was very much in need of more care and could have been improved by a lot more than 1% with a doubling of work hours spent on it.
Improving the main product or exiting products is seen as "maintenance". Industry doesn't give bonus/RSUs/promotions for maintenance. It is always gonna be a shiny new project, which gets promotions/bonus/RSUS. After getting bonus/promotions, every one (from the director level down to the bottom) will move laterally to another org. Rinse and repeat, you can see the pattern across FAANG.
That may even be OK. If it really is maintenance, maybe outsourcing it or giving it to entry-level employees may be a reasonable strategy as opposed to trying to keep more senior folks involved, if there are genuinely no interesting new angles involved.
Lots of time good ideas that are almost assuredly self evident still end up needing to be proved out. A ten line code change might take a design doc, a report justifying the impact the change will have, buy in from external teams etc.
There are pros and cons to this but I could also see other companies shipping a small change like the above toy example much much faster.
10 lines can be big or small at the size of Google. They have ~23 years of legacy, tens of billions in revenue, and a product that requires a massive technical infrastructure to operate. Over time that type of money makes a company risk averse as they can afford to be risk averse. Or to simply dump people time onto trivial activities to ensure that things go well.
Ideally they could invest in methods of blast radius protection to speed up the iteration cycle. As I recall, they still allowed teams to get a tiny slice of search traffic diverted to a custom experiment on a custom service without too much overhead.
It's interesting that I hear this story often, but then you look at Berkshire Hathaway, and huge pieces of the company now, were at the time just a piece of another company that they took over that they weren't really that interested in to begin with (ex: Real estate div)
Which demonstrates that a single company will eventually grow too large. Berkshire is successful because it owns wholly independent companies that don't need to engage in political infighting against each other for resources. We're seeing the wild success of that model with Embracer Group.
Having worked in Google like companies they always seem lure talent by dangling tasty projects in front of them. But successful projects at the scale these companies need are few and far between. The talent then starts complaining the company is not nimble enough etc and moves on. One might argue this is the natural order things. One of the reason SV has so many startups. Much of what startups do is likely not that appealing to large companies and far too risky - failing at a high rate.