I think there is something else that I find hard to explain, but it stems from the same vein.
The best way I can call it is the impedence mismatch between what business people imagine and envision, and what the real products, their code, their systems are actually doing and are actually designed to do.
It creates a kind of cost explosion in the velocity needed and it is often solved by throwing more developers at it instead of rethinking the actual design of the products so that they can better grow to support additional use cases and scale.
You can't totally call it a hack, but it kind of is. A system was designed in a way that doesn't scale to the user demand and to the additional features or the new abstractions that it wants to grow into. Instead of rethinking holistically about how that system should be re-designed to now encompass all of this new stuff, and then put the work into changing it from its current model to that new one. What people do is they break up the current system in two, so now you have two service where you had one before. And now they hire a new team of engineers, manager, PM, etc. to start working on this new half. This repeats again where each of those two half are split in half again, hiring a new team, now there are four teams and four service, etc.
As that happens, you can no longer redesign the way the systems fundamentally work, so each team accrues more and more complicated workarounds on their individual pieces and all new feature becomes cross team projects where you now need someone to coordinate the work between all teams for each little project.
Once you start down this path, there is no way out, the only solution becomes throwing even more teams at it, breaking things down again and again into smaller pieces with a whole team behind it as each piece becomes more and more complex to all work around the inherent holistic limitations that were never reconsidered.
It's a vicious cycle, the piece cannot grow in it's current state because it is too complex, break it up, have two teams tackle each half, now they can take the complexity until they themselves add more stuff to it which makes them too complex once more, break it again, add another team, rinse and repeat.
The issue is often that complexity is accidental, due to the design in place and the tech dept accrued till now, as opposed to being inherent to the domain problem. But instead of addressing the accidental complexity, it is simply broken down in two so we can throw more people behind taming it.