Are you a Technical Program Manager or Program Manager? What's the Differemce?

[#1]

Hey all! Bryan here, Community Leader for Los Angeles! 

I'm curious, how many of you here are Technical Program Managers (TPMs) vs Program Managers? 

For those of you who are Program Managers (not TPMs) - how familiar are you with the role of a TPM?

What do folks think the difference is, and how do you communicate that to your fellow PMs? 

I think about this a lot as I consider the more prominent role TPMs have these days in the software industry, especially! 

Looking forward to your responses! 

[Justin Townsend]

Hi @Bryan Guffey,

If you're willing to hear an opinion from a London-based community participant this is my take FWIW:

• Technical Program Managers (TPM)s -> tend to be in charge of projects where the lion's share of the work is technical (e.g. software, hardware development and deployments), the non-technical components of a program are (an important), but secondary, consideration. Crucially, they are also interested, able or willing to be regularly involved in the technical detail if necessary. This might mean they are able to develop respect amongst the technical contributors on the program for their ability to collaborate, or "solution-ize" at the issue or task level. This type of approach is useful since it can give the TPM an understanding of the relative importance of technical requirements and issues from a planning and critical-path standpoint.
  • TPMs are often equated with people who may have done a technical degree (e.g. Computer Science, Engineering) and my experience this is often a requirement on a job description. IMO, this is a limiting convention. Just because one understands a technical topic because of a qualification in it, is not the same as one's ability to explain it to others...
• Program Managers (PM)s -> tend to be in charge of projects where the lion's share of the work is non-technical (e.g. business transformation, divestiture / merger), or concentrate on the business aspects of running a technical program (e.g. phasing, planning, budgeting, scheduling, stakeholder engagement). Perhaps they rely on an experienced technical operator (e.g. Principal Engineer) to help them understand some of the technical details which affect a critical path.

Common amongst great PMs though, is their ability to encourage a "safe space" for optimal performance from contributors, putting people together for effective collaboration (e.g. pair-programming and shadowing).

Sure this isn't a complete answer, but perhaps others have an opinion to contribute.

Good question.

Justin