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.