What TPMs Do and What Software Engineers Can Learn From Them

A deep dive with five Technical Program Managers (TPM) on what the role is, how it evolved, and how engineers and managers can benefit from working with TPMs.

This is Part 1 on a deep-dive of the TPM role. Read Part 2 here: Scaling engineering organizations with the TPM role.

👋 Hi, this is Gergely with this month’s free issue of the Pragmatic Engineer Newsletter. In every issue, I cover challenges at big tech and high-growth startups through the lens of engineering managers and senior engineers.

Subscribe to get weekly issues - if you’re not already. It’s a good read, and the #1 technology newsletter on Substack.👇

Q: What is this TPM role you’ve mentioned in previous newsletters? I’m curious to learn more.

Great question. TPM stands for Technical Program Manager. This issue covers:

1. Why learn about the TPM role. What’s in it for engineers or engineering managers to learn more about TPMs?

2. What the TPM role is. What the role stands for, and why this role came to be.

3. What do TPMs do? Examples of areas which TPMs own.

4. The evolution of the TPM role. At Big Tech and high-growth startups in particular, this role is today more common than it used to be. How did the role evolve and why is it more common these days?

5. How do people typically become TPMs? And how do software engineers transition successfully into this role? What are things people need to be good at, to succeed in this role?

6. Working with TPMs as engineers and Engineering Managers (EM). What are good approaches? How can engineers and EMs best help their TPM counterparts?

7. What can engineers and EMs learn from TPMs? I’ve found there is much we can all learn from TPMs, and I’m sharing the most common lessons.

I first mentioned this role in the Engineering career paths at Big Tech and high-growth startups issue and expanded more on it in the article Engineering leadership skill set overlaps, in which I visualize the similarities and differences between the TPM role and other engineering leadership roles:

The TPM role and the overlap with others. Source: Engineering leadership skill set overlaps newsletter issue.

Both these articles scratched the surface of this role. In this issue, I go in-depth with five experienced TPMs working at tech companies:

• Bernard Ng, Staff TPM at DoorDash

• Grenville Fernandes, Senior TPM at Uber

• James Dayhuff, TPM at Twitter

• Sophia Vicent, Senior Director of Engineering Operations at DoorDash

• Yixin Zhu, Senior Manager of Tech Programs at Tempo, formerly Senior TPM at Uber

1. Why learn about the TPM role?

This issue covers topics relevant to software engineers and engineering managers at Big Tech and high-growth startups. How does the topic of TPMs relate?

I’ll quote James Dayhuff, TPM at Twitter, observation about this role:

'I see the TPM role as undervalued within some non-tech companies. Tech companies which understand the importance of the role and how it unlocks organizations to operate more efficiently tend to hire regularly for this role exactly because of these benefits.'

Robert Chokr, Product Director at Delivery Hero refers to TPMs as a force multiplier on a different level:

'PMs are a force multiplier. One PM is responsible for the work of ~8 engineers and a product designer. But TPMs are a force multiplier on a whole different level. They can make or break large programs where dozens of tech teams and hundreds of people are involved.

'TPMs can make the difference between a large project being delivered smoothly in 6 months, or having it choke up multiple departments during a 2-year long effort, with projects becoming the butt of the joke, and people openly talking about how bad that program/project was.

'TPMs are where it's at. But most folks don't understand this role, confusing it with Project Management.'

Emily Nava is building out a TPM team at MainStreet and was a TPM at Amazon and Twitter, previously. In an issue of TPM Stories she shares how one of the biggest challenges as a TPM is people not fully understanding this role:

'We’re at an interesting time with the TPM role in our industry, in that different companies and even different organizations within the same company vary in how they implement the role. So it can be an increased burden on the individual TPM who has to do a lot of educating about their role in parallel with driving the program. And a lack of understanding about the role can also lead to TPMs getting pulled in once a program is already in execution mode.'

Although the ratio of TPMs is relatively low compared to engineering managers or product managers, this role is steadily gaining popularity at fast-moving tech companies, especially medium to large-sized ones. We cannot talk about how Big Tech and fast-moving companies work with the efficiency they do, without diving into this role.

If you’re an engineering leader, you should already be either working partially as a TPM, or hiring one. In this issue we’ll cover ways TPMs make tech organizations more efficient. If you are an engineering manager, senior or staff engineer, you’re likely to be already doing a partial TPM role, so understanding what TPMs do might help you be more efficient. And if you’re heading up a larger organization, you might start to see the need to introduce a TPM role to keep up with your engineering organization’s growth.

2. What the TPM role is

What do TPMs do, and what does the role consist of? 

Yixin Zhu is the Senior Manager of Tech Programs at Tempo. Here’s how he describes it:

'The TPM owns the ‘when?’ and ‘who?’ questions. The PM owns the ‘why?’ and ‘what?’ The EM and the engineering team own the ‘how?’ This is the shortest elevator pitch I have.

'In practice, there are three pillars I see this role encompassing:

1. Strategy and execution. Planning, prioritization and getting things done.

2. Design and architecture. By design and architecture I mean less the engineering side, although more senior and more hands-on TPMs might get involved here, as well. I’m talking about information architectures, organization design, people processes and technology. I think of TPMs as a ‘right hand’ to the CTO.

3. Culture. Investing in the engineering brand both internally and externally. Helping with recruitment.'

Based on how Yixin describes the role, this is a mental model I’ve drawn up for it, taking into account how TPM roles make sense in engineering organizations above a certain size (usually 50+ engineers).

What do TPMs own? A mental model.

Bernard Ng is a Staff TPM at DoorDash. He shares his perspective on how the role differs at various companies:

‘The TPM role is different at companies like Google, Meta, Uber and DoorDash. Internal culture and mindset makes for differences in the day-to-day details. The role could also change based on the structure of the organization a TPM operates in.

‘In larger companies with deep hierarchies, the TPM role is often closer to how an engineering manager would operate. A significant part of your time is spent working with other TPMs.

‘In lean organizations, you don’t have the luxury of enough TPMs to cover all areas. This means, TPMs are expected to show more autonomy.

‘DoorDash right now is on the lean side when it comes to TPMs. We have around 15 TPMs for a bit under 1,000 people working in tech. At Uber, this ratio was around 70 TPMs for a tech org of 4,000 people. However, you’ll find companies like Google or Amazon where there could be 50-100 TPMs working only in one sub-organization of the company.’

Afiya Chohollo, Director of TPM at Onfido defines the role like this:

'As a function and a role, TPMs drive the delivery of company objectives through the tech organization. They do this by leading complex, multidisciplinary and cross functional initiatives.'

3. What do TPMs do?

Now that we’ve heard TPMs describe their role, let me flip it around and describe what us engineers may observe TPMs working on at most companies:

• Leading complex and long-running projects that involve many teams. TPMs owned implementing GDPR across Uber in line with the new regulations, which was well over a year-long effort. Even after the systems were updated, certain TPMs kept leading compliance-related efforts.

• Leading engineering programs that don’t qualify as products. The ownership of products and platforms is clear within tech companies. Product managers and engineering managers are on-point for these efforts and teams. But what about work that is not a product, not a platform, but is still important? Such as work like migrating from on-premises data centers to a cloud provider, or improving reliability of systems. These are areas of which a TPM might take ownership, and work with several engineering teams to prioritize work that moves the needle across the organization.

• Owning migrations and long-term tech debt efforts. If a migration or paying down tech debt can be done within a team, that team owns this effort. But what about the more common case where a migration impacts dozens of teams, or paying off tech debt needs several teams to move in parallel? Without dedicated ownership, these efforts fall between the cracks. TPMs tend to take ownership of these engineering efforts that need an owner, but for which an engineering team might not be the best owner because their incentives might be to move on quickly, rather than do what needs to be done.

• Owning engineering delivery for a domain like mobile, frontend, infrastructure. A TPM for mobile would be responsible to ensure the mobile engineering team can keep delivering at the same pace, even as it grows. A TPM here would have significant mobile domain understanding, and would aim to predict upcoming pain points, and solve for them with a variety of technological and organizational processes and also people strategy. They would work with engineers and engineering managers.

• Leading one-off, but complex and important projects. When Uber rewrote the Rider app, about 30 teams with close to 200 mobile engineers and dozens of backend engineers participated. Similarly, in 2017, Uber decided to ship tipping functionality in a matter of months. Again, TPMs stepped in to coordinate a project that spanned dozens of teams, and had to be shipped on a short deadline.

At certain companies, the TPM role is often much closer to what the CTO does. TPMs often end up working as a ‘right hand’ to the CTO, and they might own some of these areas as well:

• Engineering brand and engineering blog. Hiring and retaining engineers is more challenging than ever. One of the best ways to hire is to broadcast the excellent work these teams do, and to have this come from the source; engineers writing about their challenges and successes. Organize events where the engineering team shares their learnings with the community. An engineering brand and an engineering blog strategy can fall under the responsibility of a TPM.

• Engineering strategy. How does the engineering team plan and prioritize work? How do they get things done, and how are these tracked (or not tracked)? TPMs often get to drive the evolution of these processes – and the tooling related to them – as the engineering team grows.

• Top-level engineering programs or OKRs (Objectives and Key Results). ​​These are usually efforts around security, compliance, reliability, quality, scaling effectively, and developer velocity. They are often driven in coordination with areas like infrastructure, security, and data leadership.

• Engineering processes. TPMs could step in to drive areas like release management, incident management, collaborating with support, interfacing with vendors or reporting on measuring and reporting engineering metrics and key performance indicators.

• Engineering learning and development. Defining and driving programs to onboard engineers faster, invest in them and grow them in their careers. 

4. The evolution of the TPM role

How did the TPM role come about? Talking with TPMs, I found two routes.

Program Manager roles started to gain popularity at Microsoft, starting around 20 years ago. As Microsoft grew, the complexity of its products and the growth of the engineering teams building these products needed to be coordinated. Microsoft created the Program Manager role to solve this problem. Here’s how former Microsoft program manager Hussein Kanji described this role in 2011:

'Program Manager is a uniquely Microsoft role that is a combination of product management, project management and user interface design. At Microsoft, program managers own the product spec. They don't have any control over the engineering team, but it's their job to make sure the product is built the way customers will want it.

'At most companies, product managers are a link between marketing and engineering and have some business training (quite a few are MBAs). Not so at Microsoft. PMs are freshly recruited engineering graduates who want to do more than code, or are PMs who have grown up in the organization. They often have zero business training.

'The PMs aren't project managers either since there are others in the engineering org who make sure the releases happen on time. The PMs also don't report into engineering or marketing, so they are self standing, the only true authority they have is persuasion and the spec.'

This description of what Program Management meant at Microsoft a decade ago closely resembles how Product Managers operate at Big Tech and high-growth startups these days. 

Amanda Song was a Program Manager at Microsoft from 2017 to 2020. She describes how the role at Microsoft compares to the rest of the industry:

'On some teams, a Program Manager at Microsoft will resemble the industry definition of a product manager: they develop and advocate for the product vision, build the roadmap, interact with customers to collect feedback, and work cross-functionally with engineering, design, marketing, customer support, etc. over the product or feature lifecycle, from ideation through launch and beyond. At Microsoft, this kind of role may be referred to as a ‘feature Program Manager or ‘product Program Manager.’

'On other teams, a Program Manager at Microsoft may be closer to the industry definition of a program manager or technical program manager. This role can be heavier in terms of operations, business development, or account management. This might look like working with other Program Managers to design and execute internal business processes, communicate with partners to troubleshoot issues, and align multiple internal business or development teams.

'In Windows, for example, this can look like building and maintaining relationships with important partners up and down the hardware stack, at various levels of manufacturing, which can include: OEMs (original equipment manufacturers), who bring together all components for an overall device, such as Lenovo, Dell, and Acer; ODMs (original design manufacturers), and ISVs (individual software vendors).'

The Microsoft Program Manager role strongly influenced the rest of the industry. Microsoft was the first company to hire new grads into intern Program Managers roles, training them on the job. Several experienced TPMs today, started their careers as Microsoft Program Manager interns and carried that experience on to companies they later worked at.

Large tech companies often come to the same realization that Microsoft did: that there’s a gap in organizing teams, owning product or program goals, and working across several teams to get complex things done. 

Tech startups exiting the 'survival' stage and entering a more predictable growth stage, naturally tend to put a role similar to TPM in place. Yixin Zhu leads the TPM organization at Tempo. These are his observations on why high-growth companies often find a need for the TPM role:

‘Every year, there’s a huge number of startups founded. The majority of these startups fail, but those that survive keep growing. These companies all hit a point where they need to figure out how to optimize how they operate, how they grow their organization and think about not just technology, but people working in technology.

‘When these startups get to the stage of asking the question of ‘how are we going to grow our technology organization?’ they often don’t reinvent the wheel, but take proven approaches from other companies ahead of them. Startups stand on the shoulders of giants.

‘Take technology approaches. Twenty years ago, if you only had one machine, you had to take down your website while you made changes to it. Today, you can host your site on AWS while actively developing it, and not having to worry about downtimes. AWS helps scale your infrastructure. The same goes for scaling a technology organization. Startups take roles that worked well for other high-growth companies such as the TPM role and use it to skip to executing, instead of having to reinvent the wheel.

‘There are also more people talking about TPM roles externally. While Microsoft was the one which introduced the Program Manager role, the concept has spread since. The awareness of the role is spreading, resources like TPM Stories are being published, and more TPMs share their experiences like Sophia Vicent wrote about principles of world-class TPM teams.’

5. How people become TPMs

I asked several TPMs how they found their way into this function. All of their stories were different:

• From finance. Bernard Ng has a computer science degree and initially spent a decade working at investment banks including Goldman Sachs, JPMorgan, and Morgan Stanley. He had various roles including program management, regulatory/compliance, and sales & trading analytics. He joined Uber as a data analytics program manager, and transferred internally to TPM. Utilizing his computer science foundation and varied finance experience, he has never looked back.

• From a testing lead. Grenville Fernandes was leading a testing function at a bank, working with a dozen TPMs. His former manager asked if he would be open to taking on a part-time TPM role, which he did. From there, he moved to a TPM role at the payments tech company Ingenico, and came to Uber in a TPM role. He was the first TPM hired in the Amsterdam office, which was where we worked together.

• From software engineer. Yixin Zhu interned as a software engineer at Microsoft, returned the next year to do a Program Management internship, then interned as a software engineer at Google and worked for a few years as a software engineer at Coursera and Uber. He never felt fully at home in software engineering, and took the opportunity to move to the TPM role at Uber. The rest as they say, is history.

• Crafting an internal TPM role. James Dayhuff has a Master’s in Information Systems and Business Intelligence. He started working at Exxon Mobil in a data analyst and system support role and later on transitioned internally to a more technical role, so he could better utilize his computer science background. He became an API developer, and as the team grew, he took on the leadership of this team. It was around this time he read about the TPM role, and decided this was exactly the type of job he wanted. So he made changes to his work, started to introduce practices used by TPMs and successfully became the TPM in an organization that had never heard of the role. 

Yixin shared the observation that there is no single path to becoming a TPM:

‘The common path to become a TPM is the ‘uncommon’ one. For engineers, product managers and designers, there are paths that are tried and true. For TPMs, it’s often the case that the outliers end up here. Many of the folks don’t really fit into any of the conventional boxes. I’ve seen great TPMs come from software engineering, product management, engineering management, testing and consulting backgrounds.

‘While most TPMs in their past have done a variety of different roles, what connects them is their love of solving hard technical problems and solving them with a people, process and technology mindset.

‘This is also why there’s a huge variety of TPM roles in Silicon Valley and outside it. Every organization is different, and those organizations have different people, process and technology problems. And this is a great thing, as it creates a wide spectrum for people who want to work in tech and solve these problems, but who don’t fit into the fairly constrained box of software engineer, product manager or designer.’

Grenville shared the same observation. He categorized the most common transitions into the TPM role as being people who were previously project managers, engineering managers, business program managers, software engineers or product managers.

It’s easier to switch onto the TPM track at your current company. All the TPMs I talked with transitioned into their role at a company at which they held a different job title. It’s also the path they observed most other TPMs take. It’s definitely easier to try to transition to a new role within your current organization where you already have built up credibility. This is true not just for TPM roles, but all transitions.

6. Working with TPMs as engineers and EMs

What are good ways to work with a TPM, as an engineer, or an engineering manager? I asked this question from Sophia Vicent, Senior Director of Engineering Operations at DoorDash. Here’s advice she shared:

‘Treat it like a partnership from the start and play to the strengths of a TPM. A common mistake I see by many engineers is assuming the TPM is there to project manage or be a Scrum Master. While there are companies where the role leans towards this, if you work with a strong technical TPM, it’s a waste to put that person into this small role.

‘Find ways to really work well with the TPM. This means taking the time to get them up to speed, just like you would with a new joiner engineer. This is especially true if you’re at a younger company without much documentation, or places where it’s hard to get up to speed.

‘Know that the TPM role is breadth-heavy, but they need to gain the right amount of depth to be successful. Hopefully you’re working with a TPM who understands they cannot just go broad, but they also need to dive in. 

‘Make sure the TPM spends time with the engineers to understand the technology and decisions made. Assuming this TPM works with a broad set of teams, they want to get the right level of depth with your team, as well. Unless you have amazing documentation, you need to spend time with them to get them up to speed.

‘You should have similar discussions with the TPM that you would have with a new engineer about the technology your team uses, and the tradeoffs you’ve made. What are the constraints of your system? How are you thinking about scale, reliability and tech debt? What are your key business metrics? Upstream and downstream dependencies? How is your team organized and what does your delivery cadence look like? All of these things will factor into larger decisions that this TPM will influence. 

‘The better a TPM understands your engineering reality, the more they can push in the right areas to make the project successful, while also not going against your constraints or engineering priorities.

‘If you’re lucky to have a TPM embedded in your broader team to help with ongoing work, take advantage of this. This embedding can happen via medium-sized projects that are cross-functional, helping with planning on a quarterly or other cadence, or playing a product manager-type role in a more technical or platform space that’s missing product managers. They might come in to help improve your operational cadence or to help analyze and reduce oncall burden. They could be here to improve postmortem processes, or to track and drive migration/tech debt efforts.

‘In all the above cases, a TPM working with your team can coach and mentor more junior engineers on things that are TPM ‘superpowers’ like planning work, organizing small efforts and communicating well. Make the most out of this setup! 

‘Don’t forget what’s in it for you as an engineering manager or engineer, in working with a TPM. By being able to work with a TPM, you have someone who worries – and takes care of – the project being shipped across multiple teams. This means you can spend more time on your own work and less time worrying about other teams.

‘TPMs adding a specific value is why I don’t think TPMs should be involved in projects that involve only a few teams. In these settings they would not add much value to engineering managers or tech leads, as there’s little need for breadth. 

‘But on projects with several moving parts, the TPM takes care of making sure that the breadth of teams moves forward in a coordinated way, and in a way that dependencies are understood and accounted for. This means you won’t end up in a situation where you built what you promised, but it doesn’t match up to what the other team expected.

‘TPMs also help in decisions where you would otherwise be stuck in a deadlock. This doesn’t mean they’re making the decisions, but they will share project-wide context you might be missing, share other decisions that might impact you, and if you need a tiebreaker they can help with that as well.

‘TPMs are an ally in pushing the project to be successful. For example, if your part of the project is behind and you need extra people in order to catch up, the TPM is one who will fight for you, and work with management to see if you can get help. Or if the deadline is not realistic, they’ll push for setting it to a time that is more achievable, or helping to reduce the initial scope of the project to something that can be delivered successfully.

‘In all the above cases, it’s not you who will have to talk with tech leads from five other teams, and then update the VP of Engineering. The TPM can and will represent you, and you can keep focusing on shipping your part of the work.

‘If there is conflict between teams on which approach to take, TPMs can facilitate a discussion in a neutral way and help drive a decision that is the right answer for the project, as well as communicate the decision outcome and help the teams with resourcing to accomplish it. Their facilitation of the discussion might lead to less tension than if one of the teams in the disagreement were to take the lead.

‘TPMs can save engineering leads time, share relevant context, facilitate conflict resolution within projects and synchronize teams so they move together. They’ll help you out with parts of the job that you can do, but aren’t your ‘bread and butter,’ and it would be time-consuming for you to take on. So build trust with them, work as partners and you’ll both be better off with this approach.’

7. Learning from TPMs

What are useful approaches that engineers and engineering managers can learn from TPMs? Bernard Ng shared several:

‘The more senior you become as an engineer, the more you need to be able to manage across the organization. This is the ‘bread and butter’ of TPMs and an area you can learn from them. TPMs regularly communicate and influence cross-functional stakeholders, all the way up to directors and VPs.

‘Consider getting mentorship from a TPM if you’re at the senior-or-above levels and want to get better at influencing people, or at leading cross-team projects. I mentor software engineers and data scientists via our mentoring program at DoorDash. People come to me for help on topics including how to run programs, how to influence other engineers, how to make their presence on the team more prominently felt, or how to get to the next engineering level.

‘TPMs oversee lots of breadth across the organization and this gives them a unique perspective, as opposed to working only in a single area. Most of them will be more than happy to share approaches or even mentor, assuming they have the bandwidth.’

Further resources

How can current or aspiring TPMs learn more about the role? Here are resources TPMs recommend for learning and inspiration.

• TPM Stories: collected experiences and journeys, written by several TPMs at Stripe.

• The TPM Blog: articles, podcasts and training resources related to TPM topics. Published by former principal TPM Mario Gerard.

• TPM Career: Yev Geyfman is a Director of TPM at Salesforce and shares advice and insights in the TPM field.

• Six principles for building a world-class TPM team: a blog post from Sophia Vicent, Senior Director of Engineering at DoorDash.

• PMP (Project Management Professional) resources: several TPMs shared how PMP study materials were helpful for their roles.

• TPM job descriptions: people who successfully broke into the TPM field shared how they 'reverse engineered' the job by scouting job descriptions, and studying and practicing the topics that were expected for various TPM roles.

Closing

I find the TPM role fascinating for three reasons:

1. Every senior engineer and above already does lots of things – like leading projects – that TPMs do full-time.

2. The fastest-growing tech companies rely heavily on TPMs to scale up their engineering organization’s efficiency.

3. While the TPM role is different at each company, the role itself is spreading steadily across the industry.

For this reason, understanding the TPM role is not only useful for those working with TPMs, or who are TPMs themselves, but for anyone in tech who cares about efficiency and wants their team to execute better.

In a follow-up article, we’ll cover the TPM topic from the angle of becoming a TPM and examine common TPM career paths. We’ll also dive into how and when to hire the first TPM in an engineering organization, and how to support TPMs in their career growth.

Thank you to Bernard Ng, Grenville Fernandes, James Dayhuff, Sophia Vicent, and Yixin Zhu for sharing their expertise in their issue.

---

An ask if you’re in the frontend domain: I’m running the State of Frontend 2022 this study in collaboration with The Software House. I’ll share my own in-depth analysis of the frontend world in the newsletter after the survey closes. I’d greatly appreciate your help by filling out this 8-minute survey. You don’t need to share your email (handled by The Software House.) All newsletter subscribers will get survey results. 

---

How did you like this week’s newsletter? 🤔

Amazing •Great •Good •OK •So-so