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.

Keep in mind I said "with a good enough team".

"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.

100% management-induced problems.

Building things in house rather than buying something that is close enough is hardly uniquely a management failing.

Another issue is when micromanagement gets in the way of transmitting importing information, it becomes more than a nuisance :/

Are "people problems" essentially "leadership / vision problems" in your view?

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…

The book mentioned, "Peopleware" is probably your best resource, it's short. But sibling comment is also right on.

Technical problems are what cause the people problems though. You can't completely blame one or the other.

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.