TPM Myths & Facts - Part 2
It is so disheartening to hear the misconceptions around the Technical Program Manager role. Many TPMs get dejected by the lack of understanding and respect. These TPMs often end up moving to other functions (Engineering or Product) so they can feel a deeper sense of identity and belonging. Every role has its strengths that when leveraged correctly helps elevate the entire organization.
I am going to debunk some more common TPM Myths and TPM misconceptions, and share some facts in this post, so the technical program manager job is better understood. These are also common myths about technical project management role.
Read part 1 of this blog post for more TPM myths debunked.
Here are Top TPM Myths Explained
1. Myth: TPMs setup meetings and take notes.
No, TPMs are not calendar schedulers or note takers. While TPMs will setup relevant meetings, take notes pertaining to their program and follow up on action items as part of their technical program manager duties, they do so purely to aid the tracking of the program for which they are accountable. Unfortunately, many engineering and product folks ask TPMs to set up their meetings or default them to note taking.
If a meeting doesn’t need the TPM to be present or is not led by the TPM, then it does not need to be scheduled by a TPM.
Everyone in the meeting should take turns writing down notes and action items. In fact, it is more helpful because TPMs are driving the meeting and trying to keep everyone on track while absorbing the information being presented.
2. Myth: TPMs are glorified administrators.
No, TPMs are not secretaries or administrators and I mean this with the sincerest appreciation to all the admins out there. By saying TPMs are administrators, both functions are being insulted because they have their own unique strengths and they both keep the organizations running in their own special way.
The key here is to have empathy and respect for both TPMs and administrators. Their job is not easy whatever you may think.
Leverage each function for their strengths without conflating the two.
3. Myth: TPMs are not technical.
No, as you can see “technical” is part of the title. In fact, TPMs pride themselves on their technical expertise and judgment. While not all TPMs may code, they have the right qualifications and their ability to understand the domain, see the big picture, connect the dots and think about long term scalability and stability is what sets them apart. TPMs can change domains and may need time to ramp up but that doesn’t mean they are not technical. They do not have to design your entire architecture, but they may demonstrate technical thought leadership by asking probing questions.
Encourage their technical learning by sharing resources that you/engineering found helpful
Invite their input on technical decisions and consider their questions with an open mind
4. Myth: TPMs are just scrum masters who manage sprints.
No, TPMs are different than scrum masters.
TPM vs Scrum Master: While a Scrum Master focuses on the team and Scrum framework, a TPM looks at the bigger picture, ensuring the program aligns with the overall strategy. TPMs own and drive e2e program strategy and execution working cross-functionally across disciplines to ensure successful launch of new products/services/systems. Tracking the work done using some agile methodology is part of the job but it is not their entire job. New and junior TPMs may often start out in a scrum master role, managing in depth the sprint processes. However, for senior and seasoned TPMs, the bigger the program, the higher the chances that TPMs do not run individual team sprints or act like a scrum master.
Execution is everyone’s job and even engineers should know the rituals of agile methodologies. Engineers actually benefit by doing some of their own sprint management because it makes them better at their job and finish deliverables on time.
5. Myth: TPMs create tasks for engineers.
No, TPMs create tasks that are important for them to track the progress of the program. TPMs will create tasks at the feature or story level but any sub tasks that are purely engineering in nature do not need to be created by a TPM. TPMs can then create and track dependencies across these higher level tasks so they can create a timeline and identify critical path.
Think about this - a TPM having to create 100 tasks for 10 engineers vs each engineer creating 10 tasks - which is better?
Many granular tasks need implementation details that are best provided by engineers themselves.
6. Myth: TPMs are a support function.
No, TPMs are strategic partners to engineering and product teams. The trio of functions come together in a complementary fashion to deliver business goals. TPMs are thought leaders who leverage their deep domain expertise to manage complex and cross-functional programs. They drive the program strategy and they are equally accountable for meeting program goals. TPMs are force multipliers who help other functions focus on their core strengths so there is better visibility and predictability for executive leadership.
Treat the TPMs as equal, ideate with them, invite them to meetings (let the TPM decide if it’s relevant or not), ask for their opinion, make them part of team celebrations.
Hold the TPMs accountable by setting mutual expectations. TPMs love to have ownership and thrive in challenging environments.
7. Myth: TPMs are the same as Product Managers.
No, TPMs are Technical Program Managers which is a completely different function from Product Managers. While they do have some overlapping responsibilities, Product Managers lean more towards vision and strategy (What and Why) and TPMs lean more towards execution and delivery (When and How). Different companies have slightly different definitions for both roles. The important thing to keep in mind is that there is a place and time for both roles to coexist in one team or organization.
If you are confused on what each of these roles does at your company, ask the TPM or PM and they would be more than happy to help you understand.
Call to Action
TPMs: When you see requests or comments that trivialize your work, do the following:
Assume good intent - not everyone knows how best to work with TPMs
Politely decline stating that you do not have to be the bottleneck for small tasks
Educate them on the truth about TPM role and responsibilities, and tell them what impact you help drive
Teams (Engineers, Products…): Before you slot the TPM into a certain bucket or ask them to do work that you do not enjoy, take a pause and ask yourself the following questions:
Do I need a third person to do this job?
Do I understand what a TPM should do?
How can I leverage the TPM to increase overall team impact and meet our goals?
When you see someone else not treating TPMs with respect and dignity, then be an ally to the TPM and stand up for them. Sometimes, TPMs don’t like to say No and will just do something but internally they wish other functions don’t treat them unfairly.
Everyone: When you see a TPM fall prey to these TPM myths or common TPM misconceptions, talk to them and set expectations. Hold them accountable to do more.
Also, Read: How to Build the Technical "T" in TPM
Do you feel under valued or not well understood by your peers and stakeholders. We can help amplify your voice and demonstrating thought leadership so you are considered the most sought after TPM. Contact Us to learn about our personalized career coaching services that help you reach your career goals through excellence and meaningful impact.
Frequently Asked Questions (FAQs)
What is the primary role of a Technical Program Manager (TPM)?
The primary role of a TPM is to oversee and manage the technical aspects of a project or program. This includes coordination of work across different teams, managing project timelines, and ensuring that all technical deliverables align with the overall strategic goals of the organization. TPMs are not just facilitators but strategic partners who drive the execution and delivery of complex projects.
Comments