I don't work for an FAANG, so if someone who does comes along I'll defer to them.
What I have gathered from those who do is that it's not that there's a shortage of problems to solve in the organization, it's that the bureaucracy is so thick that they couldn't solve extra problems even if they tried.
From your references to "clients" I assume that you work as a consultant of some description. Obviously, no one brings in a consultant without having a lot for them to do. Additionally, few orgs bring in a consultant with the intention of them doing only what they're told.
But if you're just one coder among tens of thousands, that's exactly what your organization expects of you. And that's what the people who tell these stories find so draining.
> ...it's that the bureaucracy is so thick that they couldn't solve extra problems even if they tried.
This is why I called out "...very often due to non-technical factors" of what I found when I dug deeper. It is very rare I find the bureaucracy "too thick", and much more often, I find first a lack of communication, and if the communication is clarified, second I find a lack of desire to work on unglamorous, tedious, time-consuming aspects of the extra problems.
A frequent example: developer has an idea how to improve and existing process. Developer is informed they need the buy-in of SRE, Devops, and NOC teams. The presentations are made, and the team representatives/managers/directors Swiss cheese the idea pointing out all sorts of gaps to address. Endless forms to fill out, approvals to obtain, more presentations to give. Developer is dejected, and comes onto HN to say it's impossible to improve at BigCo.
When I ask what could it hurt to reach out more than halfway to those teams and find out what it would take to use this experience as an exercise to create and document a "minimal integration with stakeholder teams" package that all future projects can base themselves off of, I get met with "but it's not worth it", or "that's too much hassle", and similar fend-off-the-now-not-so-quick-hit-project explanations.
Except here's the clincher for me: I have yet to meet a BigCo team that has done this even for their big projects. No one wants to do the documentation work, nor the documentation maintenance work, because assistive infrastructure enablement isn't incentivized on annual performance reviews, only what sounds like "new progress" going up the leadership chain.
Every project ends up as a bespoke process to integrate into other teams' processes and mechanisms. The bureaucracy is so thick because no one spends the time trying to document, much less automate what processes look like from other teams' perspectives. And this is one of the pillars of my current working conclusion: everyone agrees there is constant documentation maintenance that needs to be performed everywhere, but in all these discussions, extremely rarely do I see someone say, "yeah, I use the extra time to learn some new procedure/tech, and update the onboarding/how-to documentation from the perspective of a newbie" (hugely valuable IMHO), and tons of other people slapping their foreheads and scurrying off to do the same.
Even thick bureaucracy its very self can be addressed with extra time, and that is arguably one of the most frictionless actions to take; pick up the phone/chat/email and start writing what you find out. That so, so few people kvetching about all this "boring extra time" make this frictionless action their revealed preference signals volumes to me.
I want to stress it's fine that people don't want to do this kind of work. We all have our strengths and weaknesses. But so far I haven't bought into the commonly-accepted wisdom why "soul-crushing extra time" exists in our industry, with exceptionally rare variations (like defense-related highly-compartmentalized or similar contexts).
What I have gathered from those who do is that it's not that there's a shortage of problems to solve in the organization, it's that the bureaucracy is so thick that they couldn't solve extra problems even if they tried.
From your references to "clients" I assume that you work as a consultant of some description. Obviously, no one brings in a consultant without having a lot for them to do. Additionally, few orgs bring in a consultant with the intention of them doing only what they're told.
But if you're just one coder among tens of thousands, that's exactly what your organization expects of you. And that's what the people who tell these stories find so draining.