I've heard this many times. It isn't clear what it means however. If nearly 100% of problems are "people problems", what are some examples of "people solutions"? That may help clarify.
"People problems" are problems mainly caused by lack of design consistency, bad communication, unclear vision, micromanagement.
A "people solution" would be to, instead of throwing crumbs to the developers, actually have a shared vision that allows the developers/designers/everyone to plan ahead, produce features without fear (causing over-engineering) or lack of care (causing under-engineering).
Even if there is no plan other than "go to market ASAP", everyone should be aware of it and everyone should be aware of the consequences of swerving the car 180 degrees at 100km/h.
Feedback both ways is important, because if you only have top-down communication, the only feedback will be customer complaints and developers getting burned out.
I would generalize micromanagement to "bad management". I have been empowered to do things but what I was doing was attempting to clean up in software hardware that sucked because it was built in-house instead of using the well-made external part, and on a schedule that didn't permit figuring out how to build the thing right.
The cause might not be a leader (cross functional teams are rife with such problems), but the leader has the responsibility to deal with it, so I guess it is…
People problems happen way before the first line of code is written, even when there's not even a single engineer in the vicinity, even when the topic is not remotely related to engineering.
It's just never been that hard to solve technical problems with code except for an infinitesimal percentage of bleeding edge cases.