1 point by jbarciauskas 0 minutes ago | link | edit | delete
To better understand the position Scott's referring to here, I recommend reading this Joel Spolsky article: http://www.joelonsoftware.com/articles/fog0000000034.html Of course, Spolsky was a program manager at Microsoft in the same time frame as Scott.
I can understand why a cult of this sort would be incredibly fragile. This sort of position has to be the absolute hardest position to hire for. We have all read about and/or experienced the difficulty of hiring a good engineer, but being a great engineer requires a well-definted set of skills - a strong understanding of and demonstrated experience with technical topics. A program manager, or a functional lead as they are called in many other contexts, has to have a blend of the technical and fuzzy skills that are almost impossible to identify, because the proper blend is very ill-defined.
A great program manager may not be able to write quicksort in Lisp off the top of his head, but should have a strong comptuer science foundation and understand the implications of various technical choices. At the same time, the program manager has to be able to communicate options and choices between team members with differing views, help structure the discussions around those options and bring everyone to a consensus as to the correct path to follow. The program manager must be gregarious and active in stimulating communication, but without that technical edge he will lose all credibility with his team.
By virtue of having these skills, however, as Joel argues, the program manager is able to drastically improve the productivity of everyone around him, but without having x lines of code or other quantifiable metrics to show for it, other than "shipped on time".
It is not hard to see how a position like this could fall out of the A people hiring other A people and into the B people hiring C people trap quickly.
I was a PM for Microsoft around 2003, and remember taking a few great classes from Scott Berkun.
In retrospect I wonder if the existence of the role itself is cause for so much of the slowness within Microsoft. The PM role became not so much a role as a cleanup/do-everything kind of position.
Unfortunately so many people end up just being gatekeepers or secretaries that actually get in the way of people getting work done, instead of visionary thinkers and doers that help things get done. I think Scott is on to something when he says that people now feel like 3 hour meetings, disheveled teams and failing products seem NORMAL. Someone needs to clean up the PM role, and I think that will clean up the lack of innovation at Microsoft.
To better understand the position Scott's referring to here, I recommend reading this Joel Spolsky article: http://www.joelonsoftware.com/articles/fog0000000034.html Of course, Spolsky was a program manager at Microsoft in the same time frame as Scott. I can understand why a cult of this sort would be incredibly fragile. This sort of position has to be the absolute hardest position to hire for. We have all read about and/or experienced the difficulty of hiring a good engineer, but being a great engineer requires a well-definted set of skills - a strong understanding of and demonstrated experience with technical topics. A program manager, or a functional lead as they are called in many other contexts, has to have a blend of the technical and fuzzy skills that are almost impossible to identify, because the proper blend is very ill-defined.
A great program manager may not be able to write quicksort in Lisp off the top of his head, but should have a strong comptuer science foundation and understand the implications of various technical choices. At the same time, the program manager has to be able to communicate options and choices between team members with differing views, help structure the discussions around those options and bring everyone to a consensus as to the correct path to follow. The program manager must be gregarious and active in stimulating communication, but without that technical edge he will lose all credibility with his team.
By virtue of having these skills, however, as Joel argues, the program manager is able to drastically improve the productivity of everyone around him, but without having x lines of code or other quantifiable metrics to show for it, other than "shipped on time".
It is not hard to see how a position like this could fall out of the A people hiring other A people and into the B people hiring C people trap quickly.