What is the “T” in Technical Program Management
This is the question I get asked most often.
There are many different types of program managers – operations program managers, customer-oriented program managers, market strategy program managers, logistics program managers, UX program managers, etc.. There are also program managers who work with engineers and are placed in engineering orgs — but they are not TPMs. Confused? Great! 🙃
So what is the “T” in TPM exactly?
In short, it is an individual with mastery in program and project execution, who is equally adept at leveraging their relevant technical knowledge to improve the efficacy and velocity of a software or hardware engineering organization.
I highlight the word relevant as you will often find a TPM who was a former software engineer (like myself) or a TPM who was a former hardware engineer.
Where do we typically see TPMs?
Technical Program Managers are usually embedded with an engineering team, and they are partnered with a Product Manager (PM) and Technical Lead (TL, TL Manager i.e. engineer people manager, or both). They act as the execution lead of the program, and are focused squarely on guiding the team to land high priority milestones.
How do TPMs do this?
TPMs are expected to leverage their technical domain to address technical execution needs, and they must have the technical insight to understand the technical impact and/or technical consequences in every decision.
For example:
TPMs must engage with senior engineering leadership to address and unblock technical problems for ex. point out architecture gaps that compromise technical goals
TPMs influence the design or code reviews for ex. ensuring a design meets a functional (feature) or non-functional (performance) requirement
TPMs translate design docs and feature requirements into assignable and actionable chunks of work, for ex. write technical requirements in bugs, features, create and assign user stories
TPMs drive improvements in estimation techniques to improve eng velocity and delivery predictability i.e. to meet deadlines and reduce the team’s under or overestimation of work (❤️ my personal favorite)
TPMs author technically oriented planning documents that have should have multiple approaches and can convey trade-offs, for ex. a technical deprecation or migration timeline with alternate approaches informed by technical pros/cons
TPMs develop dashboards, tools, scripts, pull requests that provide information and metrics essential to making better execution decisions i.e. performance metrics dashboard, burndown chart, etc
TPMs creating user or client facing technical documentation i.e. release docs, developer guides, internal / external communication
TPMs answer technical questions on behalf of engineers i.e. to help unblock dependent teams, support technical writers, marketing, comms, product managers, external user or community questions, etc
TPMs represent status and challenges in place of their TL, eng manager, or product manager to senior stakeholders, executive eng leadership
TPMs use a scientifically-minded approach when implementing productivity experiments that impact team execution i.e. uses a control group versus experimental group when trying out a new tool, dashboard, Agile, Kanban, etc
Here are a few examples of when you would utilize TPM (as compared to Program Managers)
Addressing accountability and ownership → Program Manager
Improving eng velocity, addressing under or overestimation of work → TPM
Facilitating prioritization with other teams → Program Manager
Deriving solutions to deconflict prioritization discussions with other teams → TPM
Managing timelines of technical dependencies → Program Manager with technical background
Addressing, troubleshooting challenges of technical dependencies and driving stakeholders to a solution → TPM
Acquiring technical resources → Program Manager
Developing estimates of technical resources using velocity data and proposing a staffing level → TPM
General status of the program, risks, challenges → Program Manager
All of the above, with the ability to communicate technical details on behalf of TL/TLMs to executive product and engineering leadership → TPM
Why do organizations invest in TPM?
Consider the list above. If not the TPM, then these responsibilities would fall on an engineering manager, product manager or technical lead. The investment in TPM enables these leaders to focus on what they do best - develop their people, innovate technically, drive strategy, engage customers, recruit, retain, and more. Not only that, execution management is a science and an art that takes years of knowledge and experience. If you have a billion-dollar investment, would you make execution a side-hustle? Best leave it to the experts.
I have seen the profession explode in popularity in my 22 years in the industry. I hope the above has been helpful in informing you of the benefits of the profession, and that it enables you to see TPM as a key strategic investment that every engineering organization should make.
Thank you for your 5 minutes and I look forward to hearing your thoughts and experience on TPM.
Yours,
Melanie