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.

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)

Berkshire Hathaway is a conglomeration of companies, each run by its own CEO. It is more like a private equity with a long horizon.

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.

In fact, planning ahead (when done properly) maximises the chance that you can be flexible.

It's hard to adapt and change flexibly if you're busy dealing with the upshot of yesterday's unforeseen disaster.

Examples of the bottom-up approach exist in very large organizations: pod shop hedge funds, investment banks, a lot of the conglomerate industrials are run the same way (although this model has become less popular after GE), some kinds of insurance.

It can and does work. But it requires getting over the instinct to control and monitor which, I think, Google will never surpass. I have been saying for years that Google is like a civil service with a small search company attached...the weirdest part is that Google has somehow maintained this fiction internally that their employees are all wonderful entrepreneurs and dynamic whilst they have grown into the tech equivalent of the DMV. Once that process begins, you will never be able to fire enough people to undo it.

Also, bottom-up doesn't work if you don't have good staff. Top-down is about turning average staff (i.e. most Googlers) into something passable. The example of GE is quite good, they empowered lots of their lower-level execs and that was a terrible idea because doing an MBA or GE's exec training does not suddenly turn you into someone who can do good deals.

You can't have good leaders who perform as such in a world where cooperate process always strives to flatten the deviation and make people interchangeable in the name of business continuity.

> A good leader doesn't need to be authoritarian in order to lead.

Bottom up doesnt mean unauthoritarian leaders.