The Technical to Customer-Focused Axis
There's a drawing I've been making for a while now that argues for a beneficial overlap in the skills for program managers and developers.
Imagine an axis that goes from "Technical" at one end to "Customer-Focused" at the other end. Let's also imagine that we can agree on what these terms mean, at least at a rough level, without going into a labored attempt to come up with definitions. Let's also imagine that we can accept for the purposes of constructive argument the simplistic notion that this is a one-dimensional, reifiable continuum, and not the rich combination of intelligence, skills, attitudes, behaviors, and aptitudes that it surely is in fact.
Technical Customer-Focused
-------------------------------------------------------------------
Case 1 - Entrepreneurs, start-ups
+-----------------------------------------------------------------+
| |
+-----------------------------------------------------------------+
Case 2 - Good overlap
+----------------------------------+
| Dev xxx|
+----------------------------------+
+----------------------------------+
|xxx PM |
+----------------------------------+
Case 3 - Bad overlap
+----------------------------------+
| Dev |
+----------------------------------+
+----------------------------------+
| PM |
+----------------------------------+
Case 4 - Bad lack of overlap
+-----------------------------+
| Dev |
+-----------------------------+
+-----------------------------+
| PM |
+-----------------------------+
Case 1 is what you get in technical entrepreneurs and small startups. Technical entrepreneurs have a rare ability to understand customer needs deeply and translate those needs into code. In small companies, on the other hand, there's no room for specialization so every employee has to run the full gamut as far as they are able. A company doesn't have to grow very big before it is happy to start moving away from this model. (Extreme Programming advocates will assert that every developer can be customer-focused, as long as the developer has ready and direct access to customers. I have seen too many counter-examples to believe that this can really be universally true.)
Case 2 is, in my opinion, ideal, even with the areas of potential overlap (marked with x's). Potential overlap invites potential friction. I believe, however, that a team that learns how to collaborate effectively and to manage the occasional overlap-related problems will function better in the long run than a team that tries to avoid turf wars by precisely delineating the Dev/PM boundary.
Case 3 is an extreme example of what happens when specialist PMs try too hard to be technical. Not only is there maximal possibility for corrosive turf wars, but there is a big gap left on the right, at the customer-focused part of the axis. The net effect is technically brilliant products that don't meet customer needs.
Case 4 is what happens when a turf war has erupted and the Dev and PM communities have contracted into their mutual domains. The net result is that PMs write requirements specs and "throw them over the wall" (or in this case, over the gap) to the Devs. Devs will increasingly argue that big parts of the product don't need to have functional requirements specs at all because everything that matters is in the code design and implementation. The functional requirements specs will also suffer from not being written with insight into whether the feature can actually be coded efficiently.
