TPM Role Overview
Learn about the key deliverables, activities, and the stakeholders for a TPM.
We'll cover the following
Let’s dive deep into the TPM role. It’s important to understand what you’re signing up for before investing a large amount of time and energy pursuing that path.
Note:
This is not meant to be an authoritative source but rather observations based on personal experience.
Technical Program Manager (TPM or TPgM)
The Technical Program Manager works closely with engineering and other cross-functional stakeholders to drive large, and complex technical programs. There are many different “flavors” of TPMs that cover multiple different domains: software, hardware, datacenter, ML, etc. However, as mentioned in the first lesson, the largest value-addition a TPM can bring to the table in each of these situations, regardless of the underlying domain, is to help teams make, communicate, and execute on good, timely decisions.
How can they do this? Let’s breakdown the role into specific deliverables, activities, and stakeholders.
Deliverables
Project plans
Document the scope, business justification, resources, and timeline for the project or program. Usually, this is a broadly shared document that is used to answer questions and manage expectations with stakeholders on the who, what, when, and why of the project/program. The common tools for this deliverable is a word document or a slide deck.Project tracker ####
The detailed work breakdown of the tasks for the project or program can be a constantly updated list of work items for programs that are recurring without a clear end date or a fixed list for clearly scoped projects. Common tools for this deliverable are spreadsheets, internal company tools, or industry tools such as JIRA.
Project communication ####
The regular status updates to stakeholders on the project/program status calls out any risks or blockers that the project/program is facing. The common tools for this deliverable are emails or in-person meetings.
Dashboards ####
The summary view of key project indicators that are updated on a recurring basis can be a task burndown chart, a customer adoption graph, or any other metric that stakeholders may be interested in. The common tools are spreadsheet charts, internal company tools, or industry tools such as Tableau.
Activities
Driving recurring and “ad hoc” meetings
Meetings are important to get people on the same page and ensure decisions are made. TPMs are responsible for making sure the right meetings happen at the right time for their project.Stakeholder management
Projects will have many stakeholders: other teams, customers, and management, just to name a few. Keeping stakeholders involved, knowing their level of involvement, and ensuring their expectations are met is critical in making sure the right people know and support your project or program.
Status collection and communication ####
This is one of the more tedious parts of the job, but it is quite important. You and your stakeholders need to know where things are at. And the people working on your project need to know that they will be accountable for delivering. That’s the primary value of making sure status is regularly collected and reported. And it’s one of the most highly visible aspects that management will appreciate.
Process creation ####
Processes are important to make sure things get done at a regular cadence with a clearly defined deliverable. People tend to dislike processes and will pushback. So you have to be able to justify any new process and constantly nag people to follow it. It’s a hard part of the job, but knowing when to create a process, how to make it lightweight and efficient, and ensuring compliance are all key TPM traits.
Risk identification and management ####
Hand in hand with status collection is being able to identify when things are going wrong or what could go wrong. Calling these risks out and working with your team on a mitigation plan is critical to making sure things stay on track. It also helps you quickly “course correct” if things are already going south.
Escalation ####
When things go wrong or a decision isn’t being made, it’s the TPM’s job to escalate the issue to the right people to make sure they are informed and can help course correct. It can be a tricky balance between ensuring you demonstrate independence without always needing to go to management for help and knowing that this is a roadblock that needs to be quickly resolved. This will usually depend on your experience, the context of the situation, and your own judgement.
Data analysis ####
Often, you’ll need to conduct some analysis to help your team better understand a problem or make a decision. Being data-driven is extremely helpful to grounding discussions in facts and resolving potential disagreements. The analysis may oftentimes require writing some SQL queries or basic scripting to gather and clean the data. It’s not always fun, but demonstrating you are analytical and are willing to get your hands dirty goes a long way in building trust and influence with your team and stakeholders.
Stakeholders
Engineering team ####
The engineering team is by far your most important stakeholder (after your manager, of course). These are the people doing the work and making sure the work gets done. It is highly important to maintain a healthy working relationship with your engineering manager and leads. Often, their feedback can make or break your performance reviews since your manager will rely on their input when determining your rating or promotion.
Product manager (PM) ####
In companies where the TPM is a separate role from the Product Manager (PM), the PM will often be the one setting the vision or direction for the product. In many cases, there can be a role overlap with the TPM since a lot of the activities and deliverables are the same. This is where it is important to have a clear delineation in roles and responsibilities. You should work with the PM to carve out pieces of the project that fits with your interest and career goals. This is easier said than done. You may need to try several different interactions before something sticks.
Cross-functional teams ####
The complex projects will often have a lot of upstream and/or downstream dependencies. The cross-functional teams can be other engineering teams, Legal, Security, Privacy, Operations, or the myriad of other roles within a company. You’ll need to actively track and manage these stakeholders since they either need to provide support or approve your project to proceed.
Management ####
Last but certainly not least, your management chain is critical in making sure you have executive support and funding for your project. It is paramount to keep these folks happy.
Final takeaways
Phew…that’s a lot! Hopefully, this lesson sheds some light on the type of work a TPM does. The important thing to remember is that every role and project is different. Some roles will require more tactical tracking and process management, while others will require more strategic planning. You’ll need to figure this out as part of the interview process and when entering to a new job. Another important caveat is that you can do all of the above and still be unsuccessful. That’s why building relationships, having important insights, and showing that you’re willing to do anything to get the job done is so important. Once you have that, it gets easier.
One final aspect to note is the “T” in the TPM role. “Technical” usually requires that you are able to dive deep into the technical details of the area you’re working on and carry on design and trade-off discussions with engineers. Some TPMs interpret this as being able to do technical tasks like configuration changes or being on-call or writing scripts. While all of those tasks are useful and should not be discounted, the most successful TPMs are those who are able to incorporate their strong technical background to influence the direction of the team, articulating tradeoffs in an architectural discussion, identifying technical risks or dependencies in a project, and appropriately costing a task to set reasonable timelines. That is far more impactful than doing “grunt” work like engineering tasks and what TPMs should be looking to do.