> There are 2,000 people at the company. About 500 of those are in the engineering organization Within that 500, about 150 work on the broadest definition of “infrastructure engineering,” things like developer tools, compute and orchestration, networking, security engineering, and so on<p>> Unless we can increase YoY growth by 5-10%, they expect us to improve free cash flow by 5-10% each year,<p>> Growth in the primary business line is shrinking<p>You know what group is in for imminent downsizing once the investors insist you try to reconcile the shrinking revenue with the increased profit expectations? Those 150 infrastructure engineering employees. They're going to be looking at the fact that they can't directly attribute revenue to 40% of their most expensive subset of employees (Maybe second to executives, but guess who gets to make this decision).<p>And then all the inhouse tooling to make that monolith work will slowly rot. They'll say something like "Oh, well we expect people operating to give some percentage of their time to maintaining common infra", but that mostly won't happen, as individual product units insist on feature churn.<p>Then this will go on for maybe another 3 years, at which point getting a change in is hell because your test suites don't work, your onboarding docs are missing a thousand tiny details and security is randomly finding a team to upgrading that damn mysql database which now has a RCE vulnerability, except all the common tooling is all a big ball of yarn that everything depends on everything else and can't be updated without refactoring the whole lot.<p>And then you'll wonder why it takes 3 months to ship a button that takes users to a static page in your application.<p>Slightly exaggerated, but I've seen this pattern too many times, so I'm generally for a lot more autonomy for teams, at the risk of some duplication.