One interesting thing to note is that as these constraints relax (business stabilizes, growth slows) the engineering teams can make better decisions in the present, clean up the decisions of the past, and reduce their overall need for people. If the company has built a money-printing machine the redundant people are then moved to new lines of business funded by the money-printer. If there's no money-printing happening, margins are super thin, and there's an incentive for the company to cut costs... where do those people go?
It is easier to solve problems by adding more people, especially when financial resources is not a constraint. However like technical debt, process and people debt will keep growing. There are some methods to have handle on it like the Spotify pod model, but no method is the magic bullet.
Every resource you add is additional cost not just on the payroll but also on the work overhead. 2x sized company will not do 2x work after all. At some point the incremental value of new resource is not worth the incremental cost.
I am not sure many startups consciously think this through while scaling up.
However I am not sure how much is strictly necessary.
I honestly think a small team could achieve lot more . You loose the agility of smaller team at >50 have large company problems without the benefit of sheer manpower 500-1000 typically brings.
Scaling devops is not as hard as it sounds . There are plenty of cloud native services which scale pretty well more or less out of the box( you still domain knowledge I.e. need to know that service’s unique limitations)
scaling it for cheap is harder, still not as hard as it used to be, plenty of mature tech is available today. Ironically devops engineers with modern cloud skills generally are more expensive than the ones who know how to stand a server in a DC.
A lot of startups like WhatsApp , Instagram built great products at scale with less than < 50 so it not impossible to achieve