The handy guide to PMs
I find myself explaining this a lot, so it’s time to write it down for reference.
In software development, one encounters 3 types of PMs: Product Managers, (Technical) Program Managers, and Project Managers. It is important to know the difference between the three.
Product Managers have an MBA. They have a deep and visceral understanding of how the money flows in their market segment. They know their competitors’ products as well as their own, and they understand technology enough to trade off between major features and inform key product decisions. They may have dabbled in code here and there, but by and large they are not “technical”.
(Technical) Program Managers have a CS degree, and likely were professional software developers at one point in their career. (Part of their authority derives from this being a credible threat: “If you won’t write that code, I will.”) They know their customers better than their own family, and they are good enough project managers not to miss too many details.
Project Managers are experts in building project plans, and may even be professionally certified in doing so (PMP, etc.). Typically, they do not have either advanced business or technical degrees, but many have gained a deep and visceral understanding of the risks, dependencies and pitfalls in professional software development.
(Note: One frequent point of confusion is that there is a non-technical definition of Program Manager as well- in traditional project management, e.g. building airplanes or bridges, a program manager is the overall coordinator of a large effort and may also directly manage a team of project managers. However, in software development, the technical definition of the role predominates. In some organizations, the abbreviation TPM is used to make it totally clear.)
The definitions above I think are fairly common, and probably won’t elicit much debate. Below is my opinion on the importance and priority of staffing these roles. Obviously, on a small software team, it makes no sense to have 3 non-coding contributors - so who do you hire first?
If you have any intention of making money from the software you are building, you hire the Product Manager first. It’s her job to figure out how the money is going to be made, and that ought to be an important prerequisite for building the software in the first place. (In startups, this role is frequently fused with that of the CEO until the company gets off the ground.)
Once you have a team of a half-dozen or more developers, a growing base of customers with conflicting requirements, a deep backlog of technical improvements to be prioritized, and generally a bit of a mess on your hands, you may find yourself needing a Program Manager. The criterion for hiring one is simple: will adding a full-time non-coding technical resource to this project improve productivity, retention and general happiness of both customers and the existing development team enough to make it worthwhile?
Once you have multiple development teams, with complex dependencies between them, sometimes with external vendor dependencies, sometimes spread across multiple sites or countries, sometimes answerable to different parts of a large organization, then you may find yourself needing a professional Project Manager. By this time the overall scope of the project is perhaps 40-50 engineers, and just communicating up-to-date status is a significant job.
Some organizations, often web development or consulting shops, use Project Managers in place of (Technical) Program Managers to coordinate projects at the small-team level (3-10 developers). This is probably fine if you’re building vanity web sites and the like, and it definitely saves money, but it is probably not a good idea if you are building more complex pieces of software.
Comments (View)
