TPMs are not always well understood. I have come across countless myths about this role. The TPM role can be broad and fuzzy which often leads to lack of clarity about TPMs really do. There are many questions about the core responsibilities of a TPM and the value they bring to technical teams. There is no universal agreed upon definition of the TPM role which can lead to confusion and misconceptions about technical program managers.
Myths about Technical Program Managers Role
1. Myth: TPMs are project managers for a product or engineering team
No, TPMs are technical thought leaders and strategic partners to engineering/product teams. They participate in full software lifecycle, right from understanding the vision/strategy, discussing requirements and technical feasibility to getting to launch on time with high quality. TPMs do not just build schedules and check things off a list. TPMs utilize their deep domain expertise to build a cohesive and holistic program execution strategy.
2. Myth: TPMs are essentially Launch/Release Managers
No, TPMs possess deep understanding of product and solutions to influence prioritization, balance short term hacks with long term scalability, assess risks/dependencies and ensure solid execution with a focus on quality. Of course many projects have an end goal which can be termed as launch or release. However, a successful launch is the culmination of immense effort made through the entire software development lifecycle.
3. Myth: TPMs are Crisis Managers
No, in fact TPMs should be seen as Crisis Preventers. Do NOT bring on a TPM when you are already in deep crisis. A TPM should be involved from the start of the program so they can leverage their technical understanding and program expertise to prevent crises and mitigate risks proactively. Firefighting with good results can feel very rewarding but true TPM skills help avoid pitfalls and prevent risks from turning into fires.
4. Myth: TPMs help scale EM/PM
No, TPMs work alongside their engineering/product partners. TPMs should never be brought on by an EM or PM to do the things they don’t want to do. TPMs are not note takers and task creators. Bring on TPMs when you have projects that are complex, ambiguous, require multi-year technical roadmaps or highly time sensitive.
5. Myth: TPMs create processes that slow us down
No, in fact TPMs are like catalysts speeding up teams through carefully formulated lightweight frameworks. These best practices help organizations build highly efficient and effective teams that can scale effortlessly to meet goals and be impactful.
What other myths have you come across? Share them in comments below.
Frequently Asked Questions (FAQs)
What are TPMs and what do they do?
A Technical Program Manager (TPM) is a special type of program management role often found in the tech field. The primary focus is on managing technical programs. TPMs drive business outcomes by utilizing deep technical expertise and building a holistic program strategy. The definition of TPM largely varies from company to company or even team to team.