OP is conflating concepts in this piece. Large, poorly maintained/designed codebases are difficult to work with, and these tend to happen more in old, big companies. But large companies can be extremely productive, and small companies can be dragged by legacy code.
For example, I worked in 20+ years old services in small/medium companies where a simple change took weeks to deploy, and where most time was spent putting out fires. Conversely I worked in green field projects in FAANG where we were able to deliver new systems quickly.
It is also patently false engineers in FAANG are universally less productive. Golden paths and internal frameworks mean in some circumstances we can move really fast. It is also untrue you always need to consider thousands of interactions and all changes are painful. That's where well designed APIs isolate your services from the rest of the world.
Or we'll designed monolithic, or well designed fp or well designed op, I think we hate companies who use op as way to make bricks for prisoners and not the paradigm in itself.
Leopold Kohr explained the fundamental underlying causes in the 1950's, this led to the "small is beautiful wave" twenty years later, and we now rediscover them.
For example, I worked in 20+ years old services in small/medium companies where a simple change took weeks to deploy, and where most time was spent putting out fires. Conversely I worked in green field projects in FAANG where we were able to deliver new systems quickly.
It is also patently false engineers in FAANG are universally less productive. Golden paths and internal frameworks mean in some circumstances we can move really fast. It is also untrue you always need to consider thousands of interactions and all changes are painful. That's where well designed APIs isolate your services from the rest of the world.