A Technical Program Manager (TPM) is a manager that helps teams deliver interdependent technical work. That is, when there are multiple teams working on a large initiative, and some teams need output from other teams to complete their share of work, that is where the TPM comes in. In this article, I will explain to you the role and nuances of the Technical Program Manager role, and how to become one.
Hello! My name is Alessandro Maggio, and I am a Senior Technical Program Manager at Amazon Web Services (among other things). What I write here, however, is my opinion and not Amazon’s. I do not represent Amazon or AWS in any way with the content you will read here, solely my personal views and experience.
Now that the disclaimer is over, let’s dive deep into Technical Program Management!
Who is a Technical Program Manager?
There are three parts to the definition of TPM: technical, program, and manager. Let’s work backward, starting from manager.
A TPM is a manager because he manages initiatives that require effort and work from other people. Because of this, we consider the TPM a manager. He needs to ensure everybody is doing what he is supposed to do, that people respect timelines, and resolve interpersonal conflicts. Sometimes, the TPM will work directly with engineers and technicians and manage their work. Other times, he will work with teams and only manage the whole output of the team.
Now, normally, a TPM has no direct reports. He needs to manage across reporting lines, this is why referent power and persuasion are important in this role.
Now, a Technical Program Manager manages a program (or multiple programs). A program, to say it according to the Project Management Institute definition, is a collection of projects that work to accomplish an overarching business objective. With this definition, each project has a separate owner, but to get most (if not all) the benefit, all projects need to be delivered.
Even more common, they need to integrate: they depend on each other, and thus require high coordination. For example, if you are building a plane, the people who build the turbine need to coordinate with the people who build the wing, otherwise the engine won’t fit. People from the turbine team will need input from the wing team, and vice versa. A program manager steps in here and manages those dependencies.
Managing programs is not enough to be a TPM, otherwise you would just be a Program Manager. The “T” is important, the technical part. As a TPM, you need to manage technical programs, which means you need to know what you are talking about. Some organizations have program managers and they put them to manage programs of all sorts, so that the same person may manage a software integration or a building renovation at some point in her career. This is not a bad approach, it works well in some contexts and it is often the only one possible for smaller companies. The TPM role kicks in when this does not cut it.
When projects have a lot of technical complexity, the technical program manager is the person you want to manage dependencies. He will understand how the projects integrate together, why some dependencies are more important than others, and how everything falls in place. This knowledge comes from domain expertise, that the technical program manager needs to have.
What are the Characteristics of a Technical Program Manager?
Let’s see what the most common characteristics for a Technical Program Manager are. This will also help you if you want to become a TPM yourself.
First and foremost, a technical program manager has strong domain expertise. He knows the domain where he manages programs extremely well, to the point that he can dive deep and have a meaningful discussion with the technicians. In fact, it is common for a technical program manager to have an engineering background. In my personal case, I lead networking programs, where I work with Network Development Engineers. Prior to my program and project management experience, I was an NDE myself. TPMs managing Software programs often have a Software Development background.
Having domain expertise means you are knowledgeable about that specific industry or sector. That, by itself, is not enough to be a technical program manager. The program management part cannot be discounted away. Instead, a TPM is also a good project and program manager. She knows how to hold people accountable, how to arrange and drive a meeting, how to escalate issues to management, how to run a Steering Committee, and so on. The program management skills must be there, and they are a mix of hard and soft skills.
Now, domain expertise and strong program management skills are enough to be a technical program manager. However, if you want to be a good technical program manager, or I would even dare to say great TIPM, you need to do something more than that. And this, as in most jobs, has to do with soft skills and how you deal with people. These are the things that will make the difference.
Since we are talking about soft skills, what makes a great TPM is hard to replicate. You won’t read this section and then have all the ingredients to become a great TPM right away. This comes with experience, but at least you know what direction you should take, and how to assess if you are moving forward.
- The great technical program manager navigates through levels: he can have a detailed discussion with engineers, and summarize it in terms of business outcomes to directors and senior managers
- Great TPMs are good at playing “what-if”, anticipate potential consequences of current actions and remove blockers in advance
- The best TPMs are comfortable with technical debt: they understand what it is (deliver a scrappy but not-so-scalable solution fast) and use it effectively. They neither dive into it, nor they run away from it at all cost. They can use it when it is the right tool.
- They can understand architectural implications of business requests, and business implications of architectural needs.
- Best TPMs can build trust relationship with stakeholders across all the organization, convince and persuade people, and influence priorities of other teams. This is crucial, as they do not have direct reports.
When you are moving on your path to become a TPM, ask yourself questions to see how well you are tracking on this scale. After a meeting, do you feel stakeholders at various levels understood the issue at hand? Did they leave the meeting feeling empowered and trusted, or did you erode some connections? There is no “one-size-fits-all” recipe, but if you look at clues if you are getting closer or further away from those items, over time you will perfect yourself.
How to Become a Technical Program Manager
Now you know who a technical program manager is, and you even know the characteristics of (great) TPMs. But if you are not a TPM yet, how do you become one? Even on this, there are many paths and roads you can follow, what I am suggesting is what worked for me.
A good path is to go from engineering to tech lead to TPM. You may even be a project manager between tech lead and TPM, as I personally did.
The first step is to start with an engineering role, where you create a product or service for your company. This is the opposite of operation or customer support roles, where you maintain an existing product but do not evolve it, and as such are more constrained in the technicalities.
Some companies, like the Big Techs, tend to have DevOps teams, where a single team does both Development (engineering) and operations on the same product. If that is the case, joining any of those DevOps teams will be fine. However, if it is a more traditional company, you are better off joining engineering. If you are out of school, joining an engineering team typically requires a degree. If you don’t have one, an easier path may be to enter an operations team and then shift to engineering once you have proved your worth. Lateral shifts are always much easier.
Once you excel in your technical engineering role, you may want to start to push for team lead or tech lead. This is not something you expect a promotion for, it is something you do organically. If there is a larger project that needs to be managed, and it will require effort from multiple people, step up and try to coordinate it. You are in the best spot to show your TPM skills here. Remember, a technical program manager manages without authority, and influence people. If you step up and lead your colleagues and peers to a business outcome, that is precisely what you are doing. You are acting as a TPM.
If you do this consistently, over time two opportunities will open up: engineering manager, or TPM. Engineering manager will be more focused on managing people and dealing with individual projects, but he will be fully accountable for those. TPMs instead manage much larger initiatives, but they collate projects of various engineering managers, and as such do not have direct accountability. They are different roles, none is better than the other, and it is a matter of your personal preference and what you excel at.
My path took a slightly different twist: after being a tech lead I detached myself a little bit from the technicalities to become a project manager for a project with many dependencies and one core team that reported to me. This enabled me to have additional visibility, that ultimately made me land in a Senior Technical Program Manager role. But I would say this step is not strictly needed.
Technical Program Manager in Summary
In short, a Technical Program Manager is a manager with no report that manages technical programs: collection of projects that deliver business outcome only when taken together. If you want to become one, you need to have technical expertise first, learn about program management, and then take on more responsibility at work when opportunities arise.
A good way to start is by applying referent power. This is the best tool to drive decisions when you do not have direct authority.
