Nah, it's because of the conjunction of two different factors:
First, changing anything large and complex with a lot of moving parts is difficult.
You can see the exact same effect in a code base as an organisation.
If your code base is small, making a change has limited consequences and you can usually predict them all up front.
If your code base is large, you lose the ability to predict what the consequences of a change are. So you need to do it to find out. If you don't have good test suites, with excellent regression tests, then the chances of missing a breaking change are good, and "doing it to find out" will result in a broken system.
Organisations don't have test suites, or regression tests. So there's a lot of effort done up front to try to minimise the impact of changes. A lot more work involved in even the smallest changes.
Secondly, small organisations are optimised for flexibility, large organisations are optimised for efficiency.
A two-person company needs to be flexible and adaptable. In startup terms, they probable haven't hit product-market fit, and are still developing their product, changing it to meet the market as they discover what the market needs. Change is constant, and so the organisation needs to be able to change fast. Doing things efficiently is premature, because the efficient process may change tomorrow and become unefficient.
Large organisations have found a business model and grown to fill it. They know exactly what they're making, for whom, for how much, and have a well-defined product and market. All the bottom-line growth will come from reducing costs rather than increasing sales. So they focus on reducing costs. But there's a trade-off between flexibility and efficiency. As the organisation becomes more efficient and more cost-effective, it also becomes less flexible. At the apex of this process, the organisation is so streamlined that any change (by definition) becomes less efficient and therefore less profitable, and therefore any change is difficult and unwanted.
First, changing anything large and complex with a lot of moving parts is difficult.
You can see the exact same effect in a code base as an organisation.
If your code base is small, making a change has limited consequences and you can usually predict them all up front.
If your code base is large, you lose the ability to predict what the consequences of a change are. So you need to do it to find out. If you don't have good test suites, with excellent regression tests, then the chances of missing a breaking change are good, and "doing it to find out" will result in a broken system.
Organisations don't have test suites, or regression tests. So there's a lot of effort done up front to try to minimise the impact of changes. A lot more work involved in even the smallest changes.
Secondly, small organisations are optimised for flexibility, large organisations are optimised for efficiency.
A two-person company needs to be flexible and adaptable. In startup terms, they probable haven't hit product-market fit, and are still developing their product, changing it to meet the market as they discover what the market needs. Change is constant, and so the organisation needs to be able to change fast. Doing things efficiently is premature, because the efficient process may change tomorrow and become unefficient.
Large organisations have found a business model and grown to fill it. They know exactly what they're making, for whom, for how much, and have a well-defined product and market. All the bottom-line growth will come from reducing costs rather than increasing sales. So they focus on reducing costs. But there's a trade-off between flexibility and efficiency. As the organisation becomes more efficient and more cost-effective, it also becomes less flexible. At the apex of this process, the organisation is so streamlined that any change (by definition) becomes less efficient and therefore less profitable, and therefore any change is difficult and unwanted.