To quote Marc Anderson, software is eating the world. It’s an expectation in today’s world that any company you interact with will have some form of online presence and tech stack. From this fact emerged the need for roles like the technical program manager.
While it’s quite recent as a job title, the technical program manager (TPM) role can be found as far back as 1967 in Melvin Silverman’s book "The Technical Program Manager's Guide to Survival." At the time this article is being written, I’m a TPM myself for major, multinational retailer Marks & Spencer.
In this article, I’ll give you an inside look at the role of a TPM and the workings of technical program management.
What is a technical program manager?
According to Joshua Alan Teter’s book ‘Technical Program Manager’s Handbook’, a Technical Program Manager is defined as:
“Both a project manager (PM) and a technical expert, and they are greater than the sum of their parts. It is the joining of the project and program management skills with technical acumen that acts as a force multiplier [allowing] the TPM to do their job better than a subject matter expert or PM alone.”
This is the gold standard definition of a TPM, but why do they exist in companies like Amazon, Google, Apple, Facebook, and Microsoft?
Simply put, with any technology strategy comes the need for people to help implement it. While project managers and program managers still have their place, the need has once again arisen for specialists. These are needed to enable effective software delivery at scale—that’s the main mission of a TPM.
This is also why a TPM is typically someone with a heavy technical background that moves into managing projects or programs of work in organizations that deliver technical solutions. Unlike a Scrum Master, traditional project manager, or program manager, a TPM differentiates themselves by having a strong technical understanding that is an asset to any technically focused project or program.
[fs-toc-omit]TPMs are often heavily… technical
Going back a few years, I used to have the title Project Manager in digital agencies designing, building, and delivering websites. I worked with others with the same job title, but I had one advantage: I knew in great detail how software products were built from a technical angle, having previously worked as a software engineer building websites professionally and as a hobby.
Other project managers who didn’t have this experience still managed projects but had to rely on the project team for ideas and answers because they had minimal technical knowledge. On the other hand, I could visualize, understand and predict the complete process end-to-end.
This meant that engineers on the project trusted me to make suggestions. They felt I understood their challenges with building websites and enabled me to plan projects in a more comprehensive manner.
Even though my job title was Project Manager, I was essentially acting as a TPM.
Eight essential skills of a TPM
At its core, the name says it all. A TPM needs to be an expert in technology and program management. But let’s break it down further into the essential skillset:
1. Technical knowledge
The ideal TPM has spent many years as a hands-on individual contributor (IC) in a technical discipline. They will probably have risen through the ranks to become a senior or lead engineer. This experience enables them to understand the intricacies of a technology program and the people delivering the work. It enables a TPM to have a respected technical opinion, spot potential improvements, and predict risks.
However, note that I said “ideal TPM”. In my experience, it’s rare to find someone with this level of technical knowledge. What I find more common is TPMs that have a solid foundational understanding of technology and an aptitude to learn new technical concepts fast. This may irk those unicorn TPMs out there, but I know plenty of TPMs that do a great job without having spent years as an IC in the past.
2. Project and program delivery
A TPM is just as likely to manage projects as programs. But, they must have the ability to manage both. This skillset is minus the technical aspect and breaks into a de facto program manager role.
For example, for projects, you need to have the ability to gather requirements, create plans, track progress, and look after timelines, scope, and quality. Whereas for programs, you also need to have the ability to manage a series of interconnected projects, dependent on each other, aiming towards achieving an organization’s strategic goal.
3. Strategic thinking
Like all project and program managers, a TPM must also be able to think strategically. When managing programs, you need to make multiple decisions and trade-offs while considering the organization's strategic aims. Understanding strategy and its current state is a must for a TPM.
4. Risk and issue management
Falling under the umbrella of project and program delivery but worthy of a separate callout is risk and issue management. Due to their technical acumen, a TPM can manage risks and issues on a technical project better than someone without a technical background. This is because they likely have experienced risks and issues first-hand in the past and can better predict and manage problems on heavy technical projects or programs.
5. Budget management
Budget management and commercial acumen are key skills any TPM needs. Aside from the typical skills of creating a budget, forecasting, budget tracking, and navigating financial risk and opportunities, a TPM can be a differentiator on technical projects and programs regarding budgeting for technical factors. For example, when negotiating with suppliers to use their highly technical systems, a TPM can navigate these discussions without bringing in technical leads.
6. Leadership and people management
As much as previous software engineers will focus on the technical word in the job title, a TPM has to be an expert in leadership and people management first. This is more important than any technical or program management skill, in my opinion. The longer I work in delivery, the more I’m convinced that to be effective, you have to be able to understand people in great depth, and that if you can have this skill, you can deliver any project or program, no matter how technical it is. TPMs need to display extremely high levels of emotional intelligence where they can empathize and influence people to follow them into battle!
7. Stakeholder and client management
Closely linked to people management, a TPM must have fantastic stakeholder and client management skills. After all, these people are likely sponsoring and paying for the work of which the result will most directly impact them. To be able to closely guide these folks through the inevitable trials and tribulations of a complex technical project or program is vital for a TPM. Great stakeholder and client management can be a lifesaver when things get rough.
8. Communication
A TPM must have excellent communication skills. They will often have to bridge the gap between technical and non-technical people, which takes a specific skill set to act as an effective translator. They will also have to be very persuasive at times, as well as communicate bad news. All of this becomes a lot easier if the TPM has great communication skills.
Nobody is the perfect TPM
Finding a TPM who excels in all of the above skills is incredibly rare. When reading Joshua Alan Teter’s book, I felt quite intimidated by the skills he talked about that TPMs must have. I had to remind myself that this is a book talking about the ideal and doesn’t necessarily represent the majority of TPMs out there.
It’s much more common that TPMs all have different strengths and weaknesses. What’s important is that you’re aware of them and take active steps towards increasing your knowledge in areas where you’re not as strong.
At the end of the day, the only true measure of a TPM is how successful their projects and programs are.
A day in the life of a TPM
My current job title is Senior Technical Program Manager, and I line manage TPMs. So let me give you some insight into what a TPM does during the course of a day!
Here are the different stages I go through in a typical day:
- Start with a catchup with the program teams to see what they completed yesterday and what they intend to complete today. A TPM can assess this against the plans they have to track progress.
- Next up could be a meeting with a vendor that wants to discuss the usage the TPM's program will use over the course of the next year. They will discuss the technical integration of the vendor’s product and try to estimate what level of service is required. The TPM will also question the vendor on their SLAs and SLOs for the upcoming year.
- A quick gap in the calendar means the TPM can make their daily check of the budgets. How are things looking? What are we forecasting? Which activities look like they will come in over budget, and which under? Do they offset each other? Does the TPM need to make some adjustments?
- A quick transition is needed into a monthly business review (MBR) with the program leadership team and key stakeholders. Here, the TPM is expected to give a rundown on the program's progress. Where is it against the schedule? What is the current budget situation? What are the current risks and issues? How are the teams feeling? Are there any blockers that the TPM needs help with? How are the dependencies looking across the board?
- Next is a meeting with some of the program’s software engineers. There is a need to migrate part of the platform to a new server, and this wasn’t factored into the initial program plan. The TPM will attend to understand the requirements and challenge the approach if need be. They may not understand every single detail of the migration, but they know enough to be able to ask pertinent questions. It’s not uncommon for software engineers to focus on ‘gold-plated’ solutions, where everything is done best practice, but a TPM may need to challenge this as time and money investments are not favorable to the gold-plated solution as a first option. They may need to push for something a little rougher around the edges but something that gets the job done for now without compromising too much on quality to introduce risk. Getting a decision like this past passionate software engineers takes skill, and a TPM is well suited to such a task. In contrast, a traditional non-technical project or program manager may struggle because the engineers may feel they don’t care about quality.
- Following this, a TPM attends a session where they talk to another team about a dependency that has fallen behind schedule. It’s a piece of work that was meant to be completed this week, but an engineer has been sick and unable to complete the work. The TPM will dig into the details of the required technical work and then canvas the organization to see if they can find any other engineer with the right skill set to get on the work. This is a quick process due to the TPM being able to understand the technical stack knowledge required and the experience levels and being able to think of candidates that match this profile.
- Next is a 1:1 meeting with their line manager, where they discuss current work but primarily focus on the TPM's development plan and well-being.
- To end the day, the TPM has a meeting with finance where they need to take the Finance Managers through the current budgets and give commentary on the variances.
The TPM then logs off for the day and collapses in a heap :)
<form>
<form-title>
Get exclusive monthly updates on the best tools and productivity tips for asynchronous remote work.
</form-title>
<form-caption>Join 100,000+ readers globally</form-caption>
</form>
What’s a typical career path for a TPM?
Just like with project management, almost nobody starts out their career with the aim of being a TPM; you tend to fall into it.
It will typically be people with a passion for technology who are highly organized, great communicators, and have an aptitude for business.
Once a TPM is established, they have many options for career progression due to the varied nature and competencies the role requires.
Very much like that of a software engineer, a TPM can choose to stay in the field but specialize as an individual contributor (IC) or people manager:
- As an individual contributor, a TPM can focus on delivering larger and more complex programs of work in a hands-on capacity. They will dive deeper into the technical topics and master their skills in all of the skills we mentioned before. In some companies, a career track enables IC TPMs to progress to more senior ranks to titles such as Principal TPM, but I find this is rare and an area that needs work in the TPM sphere. An IC TPM may even choose to go back to being a software engineer as they miss writing code.
- A TPM focusing on the people manager route will often become a Senior Technical Program Manager and manage other TPMs. They will typically not personally manage as many programs but oversee a series of programs run by their line report TPMs.
Ultimately, I believe that a TPM has the capability and versatility to move in any direction on the career ladder of a technical wing of an organization. The stronger technical TPMs could become Software Engineering Managers and eventually rise to the level of CTO, whereas the more people-focused TPMs could progress to COO levels.
Whatever your chosen career path, be sure to always consider the human aspect of programs and technology. Being a great leader is what differentiates an average TPM from a great one.
