I have this sense, and am looking for feedback (perhaps pointers to literature supporting or refuting) that one important thing that good product management can help accomplish is what I'll call "perceived job unity, mostly among engineers. There is an endemic problem in medium-sized engineering teams where the engineers don't perceive the unity of what they are doing because they are in the depths of seven different complex components. My hypothesis is that leading the whole engineering organization to understand the unity of the product is not the role of engineering managers, nor of the C-level execs, but specifically of the PMs. Can anyone point me to literature/blogs/etc. that support or refute this hypothesis?
I'm not aware of any literature related to your hypothesis but it makes sense intuitively. Self-determination theory, which seeks to identify what motivates us as humans, has as one of its pillars, "relatedness." Engineers need to feel like their work matters, PMs can help with that by sharing a vision and customer feedback that drives a group of individuals forward.<p><a href="https://en.wikipedia.org/wiki/Self-determination_theory" rel="nofollow">https://en.wikipedia.org/wiki/Self-determination_theory</a>
The most important thing product people need to understand is to not treat engineers as mindless robotic resource that you can deploy on any problem and get the output of Code. Engineers are human beings so it makes sense to create environment in which they can do their best. There are human universals like feeling of belonging, job satisfaction, flow, low stress, less chaos, appreciation that can improve team productivity. Wish there was a way to track it in a quantifiable way.
"is an endemic problem in medium-sized engineering teams where the engineers don't perceive the unity of what they are doing because they are in the depths of seven different complex components."<p>What size of team are you talking about (i.e. number of engineers)? The situation you describe might be related to the clarity with which product boundaries/scope is defined. In a product team of 5-10 engineers and one product manager, it's unusual for any individual engineer to be working on something 7 layers deep in the context of that team's product, without understanding why.<p>If you treat product management as divvying up features and assigning them to engineers from an undifferentiated pool, then the situation you describe is very likely.
Certainly, bad product management can make engineers unhappy. This includes failure to identify important features early in the development process; unwillingness to cut features to meet deadlines; waffling on what a feature should do so you end up rewriting the same thing several times, which feels like spinning your wheels; and probably several other things that come to mind right now.<p>Plus, some engineers are motivated by seeing the software they build get used and solve problems for the users - bad project management certainly makes this less likely.
Thanks, all for these extremely useful notes. To address a couple of specifics: I’m thinking of an organization at least large enough to have PMs with that title (per rahimnathwani). The specific in the specific case I’m concerned with is about 30 engineers across about 10 major components (and of course hundreds of smaller components).<p>In many cases of smaller startups, the CEO or another person with a different title is probably acting PM (per hluska).
I would read Marty Cagan's blog <a href="https://svpg.com/articles/" rel="nofollow">https://svpg.com/articles/</a> many of his posts in the "Most Popular" section address the product manager + engineer relationship.