In response to Peter Van Ooijen's, A program manager should be an architect
While I do agree 100% that an architect must be a coder, I don't agree that a PM must be an architect. I'm basing this disagreement on the idea that I the three roles for a PM are incorrect. In my position (as an Architect / Developer / Leader of developers) and my experience, I find these three roles to be more important for the PM:
- Motivate the team (no technical coaching... professionalism / work ethics coaching only)
- Organize high level resources (people and hardware/software needs for development) and timelines based on information provided by the technical lead / architect
- Report to management and interact with the customer
Note that there are zero technical (development / coding) roles in these, and little to no interaction with the technical implementation or architecture. For this to be accomplished, and where my company operates differently than Peter describes, is that the architect has the following roles:
- Coach and train the team in development practices
- Organize the work to be done, perform day to day task assignments
- Report timelines, progress, and issues to PM
By moving Peter's original "Organize the work to be done" from the role of a PM into the role of an architect, my company has been able to provide a high degree of success without requiring the PM to be current in development practices. In our company's PM role, the PM must be an outgoing person with a great personality, able to interact with the customer and the developers. We do not require that a PM be a coder, or have coding experience - but 9 times out of 10, we end up with that anyway.
From Peter's additional info on his 3rd role: "Report To Management"
"All that needs is a couple of Office macro's and a cell phone."
No macro or developer phone call can ever replace the ability for a PM to turn technical progress into a "Functional Feature" report for the customer. The customer doesn't care that we implement architecture a-b-c to provide functionality x-y-z so that implementations of 1-2-3 can be done with ... the customer cares that Feature A is partially working and they can begin testing it
...
Now, with all that being said - there is significant benefit to a PM having been a coder, but no requirement for being a current coder. A PM having been a coder means that it will be easier for the architect / tech lead to explain why Feature X will require 50% more time than originally estimated, etc. The PM can also help the architect in managing the task definition if the PM understands the coding process and how technical implementations affect feature completion. However, the PM does not have to be able to code the technical implementation to understand it this level.
I don't see how any functional development group can lump the PM and the architect together, on any project of even a moderate size (more than 1 month of development). I suppose there are plenty of companies out there, that do this. I have never worked in this type of environment, though. And honestly - I hope I don't ever have to.