A deep dive with five Technical Program Managers (TPM) on what the role is, how it evolved, and how engineers and managers can benefit from working with TPMs.
> Leading complex and long-running projects that involve many teams.
Wondering how companies are solving having multiple backlogs and cross-team projects. We've tackled the problem of team backlog, very good if you ask. But the topics like GDPR are always in vain because of the lack of understanding of priority within the team and stakeholders.
Oleksandr: for projects that are strategic at a company (or org) level, someone needs to own them, and have some level of authority (coming from e.g. the CTO or org leadership).
This could either be giving the project to a team mostly involved to own.
For GDPR, in the case of Uber, this project was put as highest priority at the CTO level, a TPM was the owner, and they assembled the team from several other teams to tackle it. If teams were dragging their feet, it went back to this priority being the top 3 engineering priorities within the company: unless teams were working on anything more important, this came first.
Much of this also goes back to how you do planning (see the planning issue here: https://newsletter.pragmaticengineer.com/p/annual-planning). These cross-team projects need to have high enough priority across the organization: else they will never get done (really!)
Having being a TPM leader for a few years, I recently moved into Engineering manager role and this resonates so well with me. Thanks for putting it together. I shared with my TPM team here as well.
I think the Venn diagram is misleading. The 'T' part of TPM is critical and to not have the TPM shown in the Engineering circle, leads to the incorrect view that TPMs are mostly concerned with non technical. I view TPMs as being an overlap between Senior Staff Eng and PM.
I do call out that all people in this picture are technical. I did not draw an overlap with "Build software" as they don't produce artifacts directly related to code (e.g. code reviews, design docs etc).
I'd hope that it's very clear from the article how technical these people are!
> Leading complex and long-running projects that involve many teams.
Wondering how companies are solving having multiple backlogs and cross-team projects. We've tackled the problem of team backlog, very good if you ask. But the topics like GDPR are always in vain because of the lack of understanding of priority within the team and stakeholders.
How other companies are approaching this?
Oleksandr: for projects that are strategic at a company (or org) level, someone needs to own them, and have some level of authority (coming from e.g. the CTO or org leadership).
This could either be giving the project to a team mostly involved to own.
For GDPR, in the case of Uber, this project was put as highest priority at the CTO level, a TPM was the owner, and they assembled the team from several other teams to tackle it. If teams were dragging their feet, it went back to this priority being the top 3 engineering priorities within the company: unless teams were working on anything more important, this came first.
Much of this also goes back to how you do planning (see the planning issue here: https://newsletter.pragmaticengineer.com/p/annual-planning). These cross-team projects need to have high enough priority across the organization: else they will never get done (really!)
Having being a TPM leader for a few years, I recently moved into Engineering manager role and this resonates so well with me. Thanks for putting it together. I shared with my TPM team here as well.
Thanks, Gargi! Glad you found it useful.
came here for Trusted Platform Modules, stayed for the insights ;-)
I think the Venn diagram is misleading. The 'T' part of TPM is critical and to not have the TPM shown in the Engineering circle, leads to the incorrect view that TPMs are mostly concerned with non technical. I view TPMs as being an overlap between Senior Staff Eng and PM.
I do call out that all people in this picture are technical. I did not draw an overlap with "Build software" as they don't produce artifacts directly related to code (e.g. code reviews, design docs etc).
I'd hope that it's very clear from the article how technical these people are!