In my interactions with program managers, a common question arises both within and beyond my workplace: “How can I transition from the role of a Program Manager (PGM) to that of a Technical Program Manager (TPM/TPgM)? Are there specific training programs or skills I should focus on developing?” This article delves into the essential differences between TPM and PGM roles and offers guidance on making a successful transition.
In the dynamic world of project management, some believe TPM holds greater significance than PGM. Yet, this perception hinges greatly on the unique culture of the organization and its dedication to technical excellence in project management. As you delve into this article, you might realize that you're instinctively applying many ideas presented here. If that sparks recognition within you, congratulations! You're already embodying the essence of a TPM. Your official title is merely a formality. Believe me, you have the power to confidently bear the TPM emblem without needing any external validation or formal recognition Your expertise speaks volumes – embrace it!
In this article, I'll explore the fundamental distinctions between TPM and PGM roles, highlight the core strengths of a TPM, and offer insights on transitioning from PGM to TPM. Keep reading until the end—I've included a couple of Lightbulb moments for your consideration.
A little bit about me: I have 26+ years of Software Product Development with 20 years as a Project → Program → Technical Program Manager. I have mentored and guided several of my direct reports, colleagues, or friends, assisting them in making a successful transition from PGM to TPM. Throughout my journey, I've honed and applied diverse TPM skill sets at renowned companies like Google, Amazon, Yahoo, Nokia, SanDisk, TCS, and more. So, rest assured, you're receiving insights directly from the source."
Who is a TPM?
A Technical Program Manager (TPM) is responsible for managing complex technical projects or programs. They typically have a strong technical background, enabling them to understand the intricacies of the projects they manage. TPMs often work closely with engineering teams and are involved in the technical aspects of the projects, making decisions that require deep technical knowledge. They bridge the gap between technical teams and non-technical stakeholders.
Responsibilities:
Technical Oversight: TPMs provide technical oversight, ensuring that the project is aligned with the organization's technical strategy.
Risk Management: They identify technical risks and challenges and develop strategies to mitigate them.
Cross-Functional Collaboration: TPMs collaborate with various teams, including engineering, product management, and sometimes external partners, to ensure project goals are met.
Who is a PGM?
A Program Manager (PGM) is responsible for overseeing multiple related projects and initiatives within an organization. They focus on the overall program's success, ensuring that individual projects align with the organization's goals and objectives. Program Managers often have a broader perspective and handle various aspects of program management, including scheduling, budgeting, and stakeholder management.
Responsibilities:
Strategic Planning: Program Managers are involved in strategic planning, ensuring that the program aligns with the organization's long-term objectives.
Resource Management: They manage resources, budgets, and schedules across multiple projects to ensure efficient use of resources.
Stakeholder Communication: PGMs facilitate communication among various project teams and stakeholders, ensuring everyone is aligned with the program's objectives.
What are the Key Differences?
The main difference between a TPM and a PGM lies in their focus and scope. TPMs focus on the technical aspects of individual projects or programs, leveraging their technical expertise to guide the teams. On the other hand, PGMs have a broader focus, managing multiple projects within a program, ensuring they align with the organization's strategic goals.
In some organizations, these roles might have overlapping responsibilities or different titles, so it's essential to understand the specific responsibilities outlined in the job descriptions within a particular context.
Lightbulb moment !
PGMs: Scratching their heads, thinking, 'Wait a minute, I'm doing all this stuff!'
TPMs: Just casually nodding, like, 'Yeah, been there, done all of that!'"
Well, in multiple ways, we are both TPM and PGM, depending on the need of the hour.
So what exactly does the 'T' stand for in TPM?
Is it Coding?
Is it Architecture?
Is it Bug fixing?
Is it crafting design documents?"
"T" in TPM signifies the technical acumen necessary to ensure the successful planning, execution, and completion of technical projects. TPMs with a solid technical foundation are better equipped to navigate the complexities of technical programs, address challenges, and guide their teams toward achieving project goals. Their expertise contributes significantly to the overall success of the projects they manage.
Do TPM’s code?
While TPMs may have the ability to write code and understand technical details, their main contribution lies in technical oversight, project management, and facilitating communication between technical and non-technical stakeholders. TPMs are more concerned with the strategic and organizational aspects of technical projects rather than the hands-on coding work, which is typically carried out by software engineers and developers.
Do TPM’s write Design Documents?
TPMs, with their technical expertise, actively participate in design discussions. They provide valuable input, especially regarding the technical feasibility and potential challenges associated with design choices. While TPMs are not typically the primary authors of design documents, their involvement is essential in ensuring that these documents are informed by technical considerations and aligned with the project's overall goals. Their role lies in facilitating collaboration, providing technical insights, and overseeing the integration of design efforts into the broader technical context of the project.
Do TPM’s fix bugs?
Technical Program Managers (TPMs) are not primarily responsible for fixing bugs in software or applications. Bugs and technical issues are typically addressed by software engineers, developers, or quality assurance professionals within the technical teams. These team members are responsible for identifying, troubleshooting, and fixing bugs during the software development lifecycle.
TPMs may play a role in the bug-fixing process indirectly. They can facilitate communication between the team members, correctly prioritize bugs based on their impact on the project, and ensure that the bug-fixing process aligns with the project timeline and goals. TPMs might coordinate bug-fixing efforts by working with the development and QA teams, helping to ensure a smooth resolution process.
If they don’t do any of the above what is the “Technical Part” in their job?
Here is a side by side comparison of some common aspects during a project life cycle
Project Vision
PGM : Focuses on the overall program strategy and goals.
TPM : Understands the technical complexities of the feature and aligns it with the program strategy.
Planning
PGM : Creates high-level project plans, allocates resources, and sets deadlines for feature teams.
TPM : Works closely with technical teams to create detailed technical plans. Considers technical dependencies and constraints.
Team Coordination
PGM : Coordinates communication and collaboration among various teams involved in the program.
TPM : Facilitates communication between cross-functional technical teams. Resolves technical conflicts and ensures alignment.
Risk Management
PGM : Identifies risks at a program level, considering impact on timelines and resources. Develops risk mitigation strategies.
TPGM : Identifies technical risks specific to the feature. Develops technical contingency plans and collaborates with engineers to address challenges.
Quality Assurance
PGM : Ensures overall program quality by defining quality standards and working with QA teams.
TPM : Focuses on technical aspects of quality, working closely with development and QA teams to ensure code quality, testing, and debugging are effectively managed. Hands on testing while team-fooding and dog-fooding.
Stakeholder Communication
PGM : Communicates program progress, milestones, and challenges to stakeholders.
TPM : Communicates technical progress, challenges, and solutions to stakeholders, translating technical details into understandable updates.
Problem Solving
PGM : Focuses on problem-solving at a high level, addressing program-wide issues and conflicts.
TPM : Engages in technical problem-solving, working with engineers to find solutions to technical challenges specific to the feature.
Decision Making
PGM : Makes decisions based on program goals, budget constraints, and strategic objectives.
TPM : Drives teams towards making technical decisions in collaboration with engineers, ensuring that technical solutions align with program goals and standards.
Implementation
PGM : Oversees the overall implementation of features, ensuring they align with program requirements.
TPM : Focuses on the technical implementation, collaborating closely with development teams to ensure the feature is implemented according to technical specifications.
Please note that the roles of PGMs and TPMs can vary between organizations, and the specific responsibilities might overlap or be adjusted based on the company's structure and requirements.
To do this successfully, TPMs must have a deep understanding of the feature's end-to-end functionality and the technical risks associated with the project. While this knowledge might not be apparent at the project's outset, the skill lies in extracting it from the engineers as the project progresses. Many times this skill is acquired by working closely with the team or on a product for several years.
Another important skill set for both PGM and TPM is to have a good in depth understanding of the whole software development process (Ideation → Production). Different companies have different processes and it's important for both PGM’s and TPMs to learn, follow and continuously educate the team on the development process and entry and exit criteria of each milestone. This will also help you to plan better and team to execute better.
Lightbulb moment ! Almost 110 out of 100 times, “Feature complete” does not mean code is ready for production ! (Yes 110 out of 100 🙂 ), and the perception of feature complete is “done”, when in reality, we are not Done.
How to move from PGM to TPM
To excel as a Technical Program Manager, being a proficient Program Manager is essential. Remember “T” + “PGM” == TPM of TPgM. So essentially it's an additional skill that you have to acquire.
Technology is very industry specific. You gain “T” by experience. Here are 6 tips for this transition:
Gain Technical Expertise:
Seek opportunities within your current role to work closely with technical teams. This could involve collaborating with engineers, developers, or other technical staff on projects.
Volunteer for cross-functional projects that allow you to apply and enhance your technical knowledge or domain expertise.
Change how you work:
Consider taking on additional responsibilities that involve technical problem-solving.
Participate in design discussions.
Translate complex requirements into easy to understand deliverables.
Work closely with Engineers to understand cross team dependencies
Play with the product when in development. Dog Food or Team Food the product. Closely monitor the details in the bugs.
Don’t be shy to ask and understand technical details (see at the end)?
Uplevel your Knowledge:
Familiarize yourself with relevant tools and technologies commonly used in your organization or your industry.
Obtain certifications that are relevant to the technical aspects of the role you're interested in. For example, if you are in the IT industry, certifications related to cloud computing, cybersecurity, or specific programming languages can be valuable.
Stay updated with the latest trends and technologies in your field. Continuous learning will not only enhance your skills but also demonstrate your commitment to the role.
Seek Mentorship:
Seek mentorship from experienced TPMs. Their guidance can be invaluable in understanding the nuances of the role and the skills required.
Show your Technical Skills:
Update your resume and LinkedIn profile to highlight your technical skills and any relevant experience you have gained.
Showcase any technical projects you have worked on, even if they were not part of your official responsibilities.
Apply for Internal Opportunities:
Keep an eye on internal job postings within your organization. Many companies prefer to promote internally for roles like TPM because internal candidates already have a good understanding of the company culture and processes.
If you are already deeply involved with various technical teams, sometimes, just asking your employer to change your title to TPM may work !
That's all there is to it. Keep in mind, there's no certification or quick 3-month course to become a TPM. It's a journey that usually begins right where you are, in your current workplace, and propels you to greater heights.
Typical details that a TPM finds out that makes them Technical (with help from Architects/SW engineers/QA)
Design and Architecture:
What is the overall design and architecture of the feature?
Are there any design patterns or frameworks being utilized?
How does the feature integrate with existing systems and modules?
Technology Stack:
Which programming languages and technologies are being used?
Are there any specific libraries, frameworks, or APIs being employed?
How scalable is the technology stack for handling potential future growth?
Data Management:
What kind of data will the feature handle?
How is the data stored, processed, and retrieved?
Are there any specific database technologies in use?
Performance and Scalability:
What are the performance requirements of the feature?
How is the system optimized for speed and efficiency?
What measures are in place to ensure scalability, especially under heavy loads?
Security:
What security measures are implemented to protect user data?
How is authentication and authorization managed?
Are there any encryption or hashing techniques employed?
Error Handling and Recovery:
What mechanisms are in place for error handling and recovery?
How are exceptions and errors logged and monitored?
Is there a failover and disaster recovery plan?
Testing and Quality Assurance:
What is the testing strategy for the feature?
Are there automated tests in place, and what is their coverage?
How is the software versioned and deployed?
Compliance and Regulations:
Does the feature comply with industry standards and regulations?
Are there any legal or compliance requirements specific to the feature?
Dependencies and Integration:
What external services or APIs does the feature depend on?
How are these dependencies managed, especially in terms of versioning and compatibility?
Maintenance and Upgrades:
What is the plan for maintaining and updating the feature after its initial release?
How are patches, bug fixes, and feature updates handled?