Non technical PMsPosted: March 2, 2004
The point in his discussion he started making before he got side tracked by weirdness was about what makes a good PM, technical or not. He states that the best have both skills nailed. I’m of the non technical variety. While I agree with Joel in theory, I’m yet to meet a “technical” PM that can manage projects like I do. Overly technical PMs tend to end up mixing themselves up in work that engineers need to be doing (architecture, etc). Also, if PMs are coding or reviewing code, they’re not PMing. That means they’re not shipping. Now don’t get me wrong, every PM needs to have some programming background, database theory, process understanding. That’s a given. But whether they need to be experts at C++, Java or other languages., I just don’t buy it unless they’re PMing Visual C++ where the end user is an engineer.
This guy in Joel’s thread nailed it. Leave it to a non technical PM to get it right :-).
I’m surprised that a couple things haven’t come up. In my years as a not very technical program manager (never at Microsoft), a lot of what I did was:
TRANSLATING. Explaining to marketing why the feature they thought of yesterday can’t be in the next version, unless they are willing to take a schedule hit. Explaining to developers why the new feature they just thought of and implemented last night has to be taken back out, because users/the customer will be more confused than pleased with it, and because documenting/testing/supporting/maintaining the feature just isn’t worth it from a business perspective. A good PM has to be able to speak marketing/sales/business speak and engineer speak, and translate between them, even though she is not either of them. I regard that as one of the critical skills of a good pm.
FORCING DECISIONS – On every project, there are dark holes no one wants to look into, decisions that are very painful for the group to make (e.g. Putting customer #1 favorite feature in will screw customer #2, and it is a terrible hack). A program manager doesn’t have to be the one who makes the decision, but he is the one who makes sure that the decision gets made at the appropriate point in the process.
PROCESS – Instilling just the right amount of process. Too much and you bog down the developers and the rest of the team in doing tasks other than creating the product, too little and you have no idea where you really are in the development process, and your CEO thinks the product is almost done (and tells customers so) when you have a months (or years) to go.
COMMUNICATING – Doing the boring stuff that developers don’t want to do and often aren’t good at doing – writing reports, holding meetings, dealing with the other stakeholders.
TROUBLESHOOTING. Finding and fixing problems before they happen.
All of these can be done well (or poorly) by a non-technical PM. I’ve seen projects with and without PM’s, and I have no trouble knowing which kind I’d rather work on. Most developers who have had both experiences have a pretty clear opion which they would want to work on too.