There’s a lot of confusion on what a technical program manager is and isn’t. It also varies wildly by each organization. Some are really technical whereas others aren’t as technical but have a lot more soft skills. I’ll get into my experiences on what the role likely is, how to get into it and where paths might go.
What is a technical program manager?
Most don’t really understand what a TPM is and isn’t. I see fairly generic postings confusing the role with a project manager or a scrum master or some sort of delivery manager on the team level.
Where the TPM role really shines is the cross functional and cross team programs where there are multiple layers and organizations. For example, you have a specific large project that encompasses multiple teams, integrations and stakeholders. A while back I spoke about dora metrics and sources of delay. The TPM helps play the right keys at the right time across the organization.
TPM’s generally own the when (what time, when is this due, forecasts etc) and the who (who are the stakeholders involved, who do we need to contact). Some companies require the TPM to be far more technical than others often substituting them with Engineering Managers. I generally find the relationship like this:
Product Owner:
- What are we building? Ie, press release item or super important initiative
- Why is this important? Save 15% customer churn resulting in XYZ saved dollars
Engineering Manager:
- How are we building this important thing? – Underlying tech, architecture etc
- When are we building this important thing (on the team)
- Who is going to build it? (on the team)
TPM (Technical program manager)
- When is the full functionality of this important thing going to be built on the organization level
- Who is going to build it across the multiple areas?
What does a TPM do day to day?
I think there’s a few areas where TPMs generally get fit into. Here’s a small sample of what we do. Most are technical with the help of engineering teams.
- Leading complex, technical multi team and multi program efforts
- Specific program management – Ie, mobile delivery. Product A (with teams underneath)
- Engineering process and strategy
- I’m not saying the TPM will drive how we architect work. However, we may have big input into how we deliver certain work across the organization. IE, what work is tracked? What and why are we using specific tools?
- Another area is process around releases, incident response, uptime/reliability and cycle time. Ie, this TPM is responsible for driving down MTTR with the teams and creating process around best practices on incident response.
- OKR and program management across the company
- OKRs are really important. If you have 20 teams and multiple stakeholders things can get messy initially. Making sure teams and the organization understand is key
- Random shit at an org that no one looks after
- Here’s this capitalization process. Go automate it with the rag tag group of engineers and manage it afterwards
Can non technical individuals become TPMs?
Yes, the path isn’t straightforward nor is it linear. TPMs are generally more social and can wear a few different hats. TPMs can come from recruiting (yes, believe me), Engineering, Finance and all sorts of walks of life. Generally what the common theme I’ve seen is solving hard problems at the organization level and not settling on the status quo. They also don’t generally fit in the classic roles of Engineering Manager, Product Manager and are often hybrids
Are TPMs project managers or scrum masters or delivery masters?
Definitely a no here. If I had to make a blanket statement it would be something like:
Project Manager: A Project Manager is responsible for the successful execution of a single project. They plan the project, schedule tasks, allocate resources, and monitor the project’s progress to ensure it is completed on time and within budget. They also manage the project’s risks and issues, and they are the main point of contact for all project stakeholders. They don’t necessarily need to have a deep understanding of the technology being used in the project, but they do need to understand the project’s requirements and deliverables.
Scrum Master: The Scrum Master is a role in the Scrum framework, which is a type of Agile methodology. The Scrum Master is not a traditional project manager but acts as a facilitator between the team and any distracting influences. They protect the team from interruptions and help them to focus on the tasks at hand. The Scrum Master also works to remove any obstacles that might be hindering the team from doing their work. They ensure that the team follows Scrum practices and principles, and they facilitate Scrum events such as daily stand-ups, sprint planning, and sprint reviews.
What are some of the downsides of a TPM Role?
A lot of the downsides involve the organization and others not really understanding what a TPM or Technical program manager is. The role is somewhat newer and career paths aren’t really defined or hashed out as much. For example, you could be a Senior TPM and an Individual contributor but after that what happens? If the organization is immature or not really clear on what. Other problems on the TPM front is that there’s generally not a lot of us at an organization. That’s not a bad thing but it could stretch your abilities thin. For example, a ratio could be 1 TPM for 50 EMs in some areas. I’ve experienced a similar ratio at times and it can be overwhelming for some.
Closing
So there’s my experience with the TPM role. I hope you enjoyed the quick article for today. I’ll be back with more software delivery metrics articles soon and some updates from the world of esports. If you have any questions just feel free to reach out as always.