The whole reason it feels understaffed is because there's too many people.
I know it sounds counter-intuitive, but software doesn't really scale linearly. Unless they're 100% independent, the communication overhead will always be there. Fred Brooks and all that.
With 7000 developers working in a connected system, it probably feels slower and less things get done than if there were less people.
It's not simple to go back to having less people, however. The architecture is most certainly tied to the organizational structure (Conway's Law), and firing people will make it worse in the meantime.
Please elaborate. It doesn't feel understaffed because of communication overhead or being in a connected system, but because of the level of responsibility (I.e. critical system) or product surface area a team is responsible for.
Sure. The things you mention (Compliance, privacy, legal, internal tooling) also have to grow together with the number of developers to scale. Not only those, but also support, QA, management, UX/UI. All those ares have to increase when the dev headcount increases. But since most of those need some degree of centralization and coordination, they can't escape communication overhead and orgs slow to a crawl.
Also, software development teams have to assume more responsibilities just to escape this communication/interconnection overhead: devops is a good example, you no longer have to depend on another team, but now you gotta do operations yourself. An example of avoiding interconnection overhead is having isolated services: now you don't run queries on team Y's database, but you still have to maintain that data on your own DB. Isolation is a good alternative, but it also has its costs.
Unless we're talking about 7000 software developers working on 400 completely different and completely isolated products and answering to different people, there's gonna be a lot of invisible communication overhead, or overhead because of the need to work together with the other 6999. We developers tend to abstract it as being "part of the job", even though it is definitely non-essential complexity.
Even consulting companies doing different projects can fall prey to that: I know lots of cases of internal frameworks/libraries/UI-toolkits being adopted to accelerate development, but they ended up being a bottleneck in development because the team that owned had a full backlog.
I know it sounds counter-intuitive, but software doesn't really scale linearly. Unless they're 100% independent, the communication overhead will always be there. Fred Brooks and all that.
With 7000 developers working in a connected system, it probably feels slower and less things get done than if there were less people.
It's not simple to go back to having less people, however. The architecture is most certainly tied to the organizational structure (Conway's Law), and firing people will make it worse in the meantime.