Technical Program Manager's Handbook E-Book

Joshua Alan Teter

• Herausgeber: Packt Publishing
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch
• Veröffentlichungsjahr: 2022

Seitenzahl: 360

Beschreibung

The technical program manager (TPM) is a relatively new role born out of the need of the tech industry to have a specialized practitioner who speaks both tech and business and leverages this bilingual talent to get results that no one else can.
This book dives into what makes a TPM tick. You’ll find out which project and program management skills will help you shine and how you can apply your technical skills for effective results. This book looks at the TPM role across the Big Five tech companies (Amazon, Google, Microsoft, Apple, and Meta) to help you discern the most effective skills to be successful no matter which company you work for.
Are you already a well-performing TPM looking to see what’s next? This book identifies the career paths for a TPM at the Big Five to help you decide the next step for you.
By the end of this book, you’ll have a clear understanding of how to be a TPM, along with a breakdown of the necessary technical and program management skills to develop a clear roadmap for your career.

Leseprobe

Technical Program Manager’s Handbook

Empowering managers to efficiently manage technical projects and build a successful career path

Joshua Alan Teter

BIRMINGHAM—MUMBAI

Technical Program Manager’s Handbook

Copyright © 2022 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Gebin George

Publishing Product Manager: Kunal Sawant

Senior Editor: Rounak Kulkarni

Technical Editor: Jubit Pincy

Copy Editor: Safis Editing

Project Coordinator: Deeksha Thakkar

Proofreader: Safis Editing

Indexer: Hemangini Bari

Production Designer: Shyam Sundar Korumilli

Developer Relations Marketing Executive: Sonakshi Bubbar

Business Development Executive: Debadrita Chatterjee

First published: December 2022

Production reference: 1251122

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80461-355-9

www.packt.com

To my partner, Courtney, for encouraging and supporting me on this journey. Without her, this book and the career that formed it would not have been possible.

– Joshua Alan Teter

Foreword

For the past 8 years, I have had the absolute pleasure to count Josh Teter among my most valued and respected friends and colleagues. Josh is a leader not only in terms of the work of being a Technical Program Manager (TPM) but also, more importantly, he is a champion and thought leader for what it means to be a TPM. He shaped my understanding of what a TPM is and does, and what it means to do this job well. In this book, The Technical Program Manager’s Handbook, Josh will share his unique and valuable experience and philosophy on the special and crucial role of a TPM in today’s technical industries. His journey through this industry has given him a rare perspective on the needs of technical companies and how TPMs enable successful programs by providing a critical bridge between the many other roles and disciplines in the field. In our shared years at Amazon, I have been impressed by Josh’s growth in and mastery of this unique and challenging role.

In this book, he sheds light on a role that is still in the process of defining itself. He shares the ways in which it shares skills with adjacent roles and illustrates the unique skills and functions of the TPM role. Most importantly, he teaches fundamental skills for doing the job well and avoiding classic pitfalls.

In reading The Technical Program Manager’s Handbook, you will learn about the fundamentals, techniques, and best practices for driving clarity and planning, understanding, and communicating the status, progress, and challenges in technical projects and programs. You’ll understand how to apply this to the programs and products you will manage in your own role, and how to make a positive impact on the teams you work with. By the end, you’ll have a clear understanding of the balance and depth of a TPM’s technical role as well as their role as leader and driver.

You will see how a master TPM guides major projects and enterprise-scale programs toward success while optimizing the skills and responsibilities of everyone they work with.

As you read through this book, Josh walks you through his years of hard-won experience as a world-class principal TPM. As a natural teacher, he has created a path that is engaging and informative for you to explore. In his examples and anecdotes, you’ll see the reality of theory versus practice, and understand the purpose behind everything a TPM does. By the end, you’ll be ready to continue your development as you apply what you’ve learned to this ever-changing field.

Take this along with you and join the ranks of the TPMs making a big impact throughout the technical fields.

Ben Tobin

Career and Leadership Coach, Ben Tobin Coaching Former Software Development Manager, Amazon

Contributors

About the author

Joshua Alan Teter is a principal technical program manager at Amazon. He has been in the tech industry since 2007, starting out as a software developer at Weatherford Laboratories. His passion for program management started at Hewlett Packard in 2012 where he joined as a technical lead and oversaw a team of developers. In 2013, Joshua moved to Amazon to join the Tax Services group and helped the team grow from 35 to 280 people. In the years since joining, he has received his Project Management Professional certification and run projects to help open new Amazon marketplaces, launch new products and services, and most of all, lead innovation in terms of tax compliance with high-profile legislation, such as acting as a marketplace facilitator in the United States and in line with Brexit, along with related legislation on EU imports.

I want to thank my wife for being with me on this journey and as a soundboard for the ideas that went into this book. I also want to thank Ben and Sandra for their insight and guidance – this book would literally not be the same without their input. And to the team at Packt for their help and support throughout the process.

About the reviewers

Sandra Boudreau retired from Amazon after 1 year as an SDM and 5 years as a TPM following her 15-year career as a software developer, mostly in the military defense industry. Her career highlights included launching Amazon’s tax calculation solution in Brazil and launching Amazon Prime membership in India, as well as developing solutions for the Canadian military as a lead software developer on the trials and demonstrations team at General Dynamics Canada. She is now living in her dream house on the shore of a lake in Alberta, Canada and just starting to put a dent in her Steam backlog.

Ben Tobin spent 20 years in the software industry wearing many hats, most recently as a software development manager at Amazon. His path through the tech industry included working as the director of a small tech company and then dipping into the world of a DevOps engineer before returning to software engineering again and discovering management. In the process, he has interviewed hundreds of candidates and considers developing good engineers into great ones among his greatest accomplishments. He is now a career coach specializing in tech industry careers, engineers, career transition, and ADHD as the founder of Ben Tobin Coaching.

Angel Martinez has experience managing projects across 4 industries over 12 years. He is currently a manager and TPM at Google, focusing on data center networking deployments. He received his BS in mechanical engineering from Worcester Polytechnic Institute. Angel began his career as an associate in a leadership development program working on consumer products. He then transitioned into the transportation and product-building industries. Outside of work, he enjoys spending time with his wife and three children and, with any remaining time, playing indie board games and doing woodworking.

Nirbhay Anand has worked in the role of TPM and completed a master’s in computer science and an MBA, with 16 years of industry experience in software product development. He has developed software in different domains, such as investment banking, manufacturing, supply chain, power forecasting, and railroad contract management. Currently, he is associated with CloudMoyo, a leading cloud and analytics partner for Microsoft. CloudMoyo brings together powerful BI capabilities using the Azure data platform to transform complex data into business insights.

Table of Contents

Preface

Part 1: What is a Technical Program Manager?

1

Fundamentals of a Technical Program Manager

Understanding the modern TPM

Old title, new meaning

Learning the fundamentals

The Systems Development Life Cycle

Exploring what makes a TPM thrive

Driving to get things done

Driving towards clarity

Communication bridges

Comparing adjacent job families

Wearing many hats

Exploring functional competencies across the industry

Insights into the TPM life from interviews

A quick look into the main TPM career levels

Summary

2

Pillars of a Technical Program Manager

Understanding project management

Exploring the typical project management tactics

Diving into program management

What is a program?

Typical program management tactics

Exploring the technical toolset

Discovering the effectiveness of your technical toolset

Summary

Part 2: Fundamentals of Program Management

3

Introduction to Program Management

Introducing the Mercury program

Mercury program scope

Mercury project structure

Examining the program-project intersection

Exploring the management areas

Project plan

Project and program risks

Stakeholder plan

Summary

4

Driving Toward Clarity

Clarifying thoughts into plans

Using clarity in key management areas

Planning

Risk assessment

Stakeholders and communication

Finding clarity in the technical landscape

Summary

5

Plan Management

Driving clarity from requirements to planned work

Project management tools

Diving deep into the project plan

When planning has to be quick

Defining milestones and the feature list of a plan

Planning resources in a technology landscape

Prioritization

Team overhead

Tooling for resource planning

When planning has to be quick

Exploring the differences between a project and a program

Tooling

Planning

Knowing when to define a program

Summary

Further reading

6

Risk Management

Driving clarity in risk assessment

Risk identification

Risk analysis

Updating the plan

Risk tracking

Documenting the progress

Tools and methodologies

When risk assessment needs to be quick

Managing risks in a technology landscape

Technical risks in the Mercury program

Exploring the differences between a project and a program

Assessment

Summary

7

Stakeholder Management

Driving clarity in stakeholder management

Stand-up

Status update

Monthly business review (MBR)

Quarterly business review (QBR)

Communication timing

Defining your stakeholders

Exploring the dos and don’ts for status reports

Managing stakeholders in a technology landscape

Communication systems

Tooling

Technical versus non-technical stakeholders

Exploring the differences between a project and a program

Scheduling for natural accountability

Leadership syncs

Summary

8

Managing a Program

Driving clarity at the program level

Defining boundaries

Deciding when to build a program

Building from the start

Constructing a program mid-execution

Tracking a program

Program planning

Risk management

Stakeholder management

Summary

9

Career Paths

Examining the career paths of a TPM

The path to becoming a TPM

The paths of a TPM

Exploring the IC path

Exploring the people manager path

Summary

Part 3: Technical Toolset

10

The Technical Toolset

Examining the need for a technical background

TPM specializations

Technical proficiencies used daily

Using your technical toolset to wear many hats

Defining the technical toolset

Code proficiency

System design

Architecture landscape

Summary

11

Code Development Expectations

Understanding code development expectations

No code writing required!

Exploring programming language basics

Diving into data structures

Space and time complexities

Data structures

Learning design patterns

Creational design patterns

Structural design patterns

Summary

Further reading

12

System Design and Architecture Landscape

Learning about common system design patterns

Model-View-Presenter

Object-oriented architecture

Domain-driven design architecture

Event-driven architecture

P2P architecture

Service-oriented architecture

Client-server architecture

Design considerations

Seeing the forest and the trees

Examining an architecture landscape

Summary

Further reading

13

Enhancing Management Using Your Technical Toolset

Driving toward clarity

Planning

Risk management

Stakeholder management and communications

Resolving conflicts

Planning

Risk management

Stakeholder management and communication

Delivering through leadership

Summary

Index

Other Books You May Enjoy

Part 1: What is a Technical Program Manager?

The Technical Program Manager (TPM) role has been part of the technical industry since the beginning but is still shrouded in mystery. This part aims to set the foundation of where the TPM role came from, what it is, and why it is an important and in-demand position in the industry.

This section contains the following chapters:

Chapter 1, Fundamentals of a Technical Program ManagerChapter 2, Pillars of a Technical Program Manager

1

Fundamentals of a Technical Program Manager

The role of a program manager, in some form, has been around for as long as humans have organized to accomplish a goal, and the Technical Program Manager (TPM) naturally followed as a result. The TPM plays a powerful role in any technical project or program and has carved its way into the tech industry culture as a mainstay position right alongside software and hardware developers, development managers, and product managers. Even with its ubiquitous role in the industry, the question of what a TPM is and how can we be effective practitioners of this kind is still asked on a daily basis. This book aims to correct that.

In this chapter, we’ll start by discussing how the TPM role became what it is today. We’ll do this by exploring the roots of the TPM, the generalized program manager role, and the skills and traits that we share. We’ll round this out by exploring the basic requirements that are specific to our specialization – the systems development life cycle.

With the fundamentals under our belt, we’ll explore the specific attributes that help a TPM thrive at their job. With a better understanding of the TPM, we can widen our perspective to look at the roles adjacent to the TPM to see how we complement one another and how we can fill in the gaps that our team needs us to fill.

Lastly, we’ll look into the industry to get a grasp of how the TPM role is defined holistically by exploring job postings, as well as interviews I conducted with fellow TPMs from various companies.

In this chapter, we will explore the fundamentals of the TPM with the following:

Understanding the modern TPMLearning the fundamentalsExploring what makes a TPM thriveComparing adjacent job familiesExploring functional competencies across the industry

Understanding the modern TPM

In the 1967 book, The Technical Program Manager’s Guide to Survival, by Melvin Silverman, the author defines a program as an organization created to accomplish a specific goal. This organization was a group within a company that existed for this sole purpose and was to be dissolved once the goal was realized. You can see where the computer definition of a program gets its origins – a bit of organized code that executes to accomplish a task! Once the task is complete, the program would terminate.

I found Mr. Silverman’s book while attempting to uncover the origins of the TPM role. What I found is similar to the evolution of the word program. As it turns out, Silverman’s book was one of the first books that used the term technical program manager, though it only shows up on the title page – the rest of the book just talks about program managers. Elsewhere in the 1970s and 1980s, the term pops up in various United States government papers, listing someone as the TPM for a given project at NASA, the Department of Energy, and the Department of Defense, to name a few. This had me perplexed, as I couldn’t see any role or definition that was recognizable as those of today. So, since Mr. Silverman defined program, I found the definition of technical in the Oxford English Dictionary:

technical (adjective). 1. relating to a particular subject, art, or craft, or its techniques, and 2. of, involving, or concerned with applied and industrial sciences.

What we commonly refer to as a TPM —where technical denotes a background in computer science—is actually just one of many instances in which the term technical denotes using a specialization.

As far as the technology industry is concerned, I identified the use of the term TPM at least as far back as 1993, though I suspect it has been in use in the industry as long as the industry has existed given its prevalence in other industries from the 1960s onward.

Old title, new meaning

While researching the origins of the term TPM, I utilized Google’s Ngram Viewer, which indexes word usage in books and government publications by year between 1800 and 2019. Using the Ngram Viewer results as a starting point, I researched dictionary definitions, half-century-old books, and US government publications from NASA, and found that the TPM title has been around for a while. However, as I’m sure many readers are thinking, it feels as though it’s a very recent addition to the workforce. I remember when I was first approached to interview at Amazon for a TPM role, I was confused as to what it was. I asked, and sure enough, it was roughly what I was doing professionally but the company I was at simply didn’t use that term. In fact, very few companies seemed to be using the title in 2013 – let alone the 1990s!

Figure 1.1 shows the Google Books Ngram Viewer results for “Technical Program Manager” from 1955 through 2019 in the English (2019) dataset with smoothing set to 3. This graph was generated via http://books.google.com/ngrams with these settings:

Figure 1.1 – Google Ngram Viewer results of the occurrence of the term “Technical Program Manager” from 1955 to 2019 with a smoothing of 3

Figure 1.1 shows that there is a very large uptick to the highest vertex for the term TPM in the year 1995 – the early days of the World Wide Web and the mad dash of startups rushing towards the year 2000. With these technology companies sprouting up, the need for specialized program management arose – people with a background in and knowledge of the systems being developed so they could be better facilitators and drivers of these new programs and websites. As is the case in the technology industry, trends that start within the few companies at the top slowly make their way down through the rest of the industry until they become common. In some cases, this trend is still working its way down in the industry, as some companies are still not fully aware of the position and its benefits. I believe this explains the lag in the term being seen in publications and more commonly used in the industry.

Now, here we are today with a title used to denote a specialized form of program management being wholly taken over by the tech industry to mean a program manager with a background in computer science or engineering – thus, an old title and a new meaning.

We’ve explored a bit about where the title of TPM originated outside of the tech industry and its transformation into a specific type of specialized program manager. Next, we’ll review the fundamentals of a TPM.

Learning the fundamentals

Throughout this book, we’ll discuss many concepts that are core to any program manager, as well as some that are more specific to the TPM specialization. Let’s briefly discuss some of these terms so that we have a shared foundation to build upon.

Let’s tackle some of the key management areas that project and program managers have in common. As we’ll discuss more in Chapter 2, these are shared across all program manager roles, including specialized roles such as the TPM.

Project planning is where we work through requirements, resourcing, and constraints and develop an action plan. This makes up the backbone of our work – all the other management areas build from this or feed into it and it is paramount to a successful project. In Chapter 5, we will go into further detail on this.

Once you have a project plan, you will analyze the roadmap and identify any risks that could arise. These can be related to tight scheduling, resourcing constraints, project dependencies, or scope concerns. Depending on the risk, you may amend your project plan to help mitigate it (such as swarming – or increasing resources on a particular task to get it done quicker – to alleviate scheduling concerns).

Throughout these stages, you will be engaging with your stakeholders to provide insight. Requirements often come from one or more of the stakeholders and they may identify risks or mitigation strategies for reducing risks. You’ll also develop a strategy and cadence for regular communication with your stakeholders called a communication plan.

Figure 1.2 illustrates the key management areas we’ll discuss and how they influence each other:

Figure 1.2 – Key management areas

In the preceding diagram, we can see that both project planning and stakeholder management have central roles during the life of your project. Risk analysis and strategies feed into the initial project plan as well as act as continuous feedback. As a risk arises, the schedule may need to be adjusted. The same is true for resource management – if you lose or gain resources, your project plan will need to be adjusted. The available resourcing also plays heavily into your initial timelines. Though some organizations resource based on an optimal plan, in that they will determine the quickest most efficient path to completion and resource according to this need, most tech companies provide resourcing based on prioritization of the project and the schedule adjusts based on what is available. If the project is deemed to be a high priority, more resourcing may be given to hit a specific date, and conversely, may be given less resourcing if there is higher priority elsewhere.

Each of these management areas also feeds directly into stakeholder management – especially around standard communication routines. Any changes in the schedule, resourcing, or risk realizations should be immediately communicated by the TPM to the appropriate groups of people based on the communication plan.

Now that we’ve covered the program management fundamentals, we’ll move on to concepts that are aligned more closely with the technical specialization aspect of the role.

The Systems Development Life Cycle

The Systems Development Life Cycle (SDLC), sometimes written as Software instead of Systems, is fundamental for a TPM to understand, as it is central to both software and hardware development. As it is a cycle, by nature, it is iterative. Figure 1.3 illustrates the cycle, starting at the top with requirements analysis and following clockwise to come back around to this initial step:

Figure 1.3 – The SDLC

The number of phases in the SDLC can vary depending on the situation. This configuration incorporates what I see as the main phases that need to be involved for the cycle to be successful. Starting at the top, the flow is as follows.

At the beginning of a project, the SDLC starts with the requirements analysis phase. These may already be well established or are newly discovered or added requirements that need to be broken down. Once these requirements are better understood, the design phase is started, which takes the requirements and builds a design that meets the requirements. The design then drives the implementation of the actual product, which then leads to testing. The final phase is evaluation or iteration. This step involves looking at the product and looking for improvements. These improvements may also come from feedback from stakeholders and customers. Once they are identified, you begin requirements analysis once more and the cycle continues. Though this looks to be a waterfall approach, where all steps of a phase such as requirements gathering are completed before moving on to the next phase, this cycle can happen as often as needed. A single requirement may go through this entire cycle while another is being clarified and may proceed to design much later. To that end, the cycle is utilized in waterfall, agile, and hybrid environments.

Many other pieces can contribute to the technical fundamentals, which we will cover in Part 3 in more detail. Those skills will vary from company to company, as well as from team to team within a company, as the needs of that team can vary. Keeping that in mind, the SDLC is a fundamental understanding across all variations of being a TPM.

Now that we’ve covered the fundamentals, let’s take a look at what skills or traits make a TPM the most successful at their role.

Exploring what makes a TPM thrive

This topic comes up in every interview I’ve conducted for the TPM position. So, I’ve put some thought into everything that a TPM does. The items I’m going to discuss are not qualities specific to a company, team, or variation on the TPM role but are transitive from one position to the next.

Driving to get things done

First and foremost, for a TPM to thrive, they need to focus on pushing forwards and getting things done. It sounds a bit cliché as though you are reading it from a job description, but it is resoundingly true. Our innate drive to solve roadblocks, build the plan, mitigate risk, and drive towards deadlines are key to a project’s success. We don’t want to lose momentum because the second we do, we risk losing all progress and having to start over. This may be because, during the time the project is blocked, the individuals working on it may move on or lose context as priorities change, necessitating more time to ramp back up. It is in our best interests to resolve issues quickly because keeping engagement, focus, and motivation facilitates an immediate and more dedicated response.

This is a trait that isn’t always present in adjacent roles to the TPM, such as the development manager and the product manager. I believe this is because the primary function of those roles is different from the TPM role. For instance, a development manager’s main focus is their people, and a product manager’s focus is their product. For the TPM, our focus is the project or program – this is what our drive and perspective hone in on. A blocker in a project blocks our main purpose, so it is extremely important to us. This same blocker may be overshadowed by a performance review or by the bigger picture of the product roadmap in the other roles.

Driving towards clarity

The second trait that makes us thrive is when we take that drive, and we drive towards clarity. This trend to clarify can come at any phase or stage of a project or program. It’s easiest to see during the requirements and project planning phases, as clarifying is a main attribute of the planning phase – clarifying requirements, clarifying scope, clarifying the communication strategies, important stakeholders, and so on.

However, driving towards clarity doesn’t stop there. Every roadblock we encounter requires us to add clarity. First, we ask about the problem, the people or systems involved, any proposed solutions, and paths to escalation. Then, we take all of this data and define the problem and solution. We define the problem to make clear that our solution is fixing the right thing. Think of it as asserting your acceptance criteria for a development task.

One way in which we drive clarity plays off of the last critical trait to make a TPM thrive, the communication bridge. We’ll talk a lot about communication throughout this book, but this is a special form of communication that takes our technical background into account.

Communication bridges

Since we have a technical background, not only can we talk with our developers, but we can also understand them! This is critical for our ability to understand the tasks it will take to complete a project and to push back on estimates or provide feedback. This skill also allows us to explain the work of our developers to other stakeholders. We can take highly technical information and transform it into language that a VP of marketing will easily understand.

This ability to translate from technical to non-technical works in reverse as well. In fact, we rely heavily on this early on in a project during requirement analysis. We take business requirements and translate them into functional specifications for our development team. We understand the business and their needs, and if required, we understand their knowledge domain. For instance, if our business team are accountants, then we have to understand accounting – what they do, what pain points they have, and what jargon they use. Knowing the domain isn’t always required to land a job, but the ability to learn the domain on-the-job is key to being a successful TPM.

By understanding our business and their needs, and our development team, we effectively bridge the communication gap between business and technology. From a career growth perspective, this soft skill is by far the most important skill to perfect. Due to this, it is also the skill that shows up most in the growth category for career progression. To improve this skill, ensure you practice active listening by staying engaged with the speaker, affirming your understanding through body language, and following up with questions. This is a skill that I am still perfecting myself. I grew up in an environment where it was common to interrupt or talk over others during particularly engaging conversations. Though this can be fine among friends when talking about trivial matters, this is very disruptive in a work environment – especially given that at work, we are often trying to solve a problem. When you interrupt, you aren’t taking in what the other person is saying. Instead, you are looking for a space in the conversation to insert your own thoughts and looking for this opportunity prevents us from fully taking in what the other person is saying. Active listening will ensure that you truly understand the point of view of the other person. Often, this information can build on your understanding of their problem. Follow-up questions can fill in the gaps in your understanding to paint a more complete picture of the situation. Over time, you’ll understand your business teams and their domains, which, in turn, helps you become a more effective communicator. The better you understand the pains of your business team, the better you can relay that to your development team in your functional specifications and conversations about scope. The more they understand, the better the outcome of the software and the more successful the project will be.

We now understand what makes a TPM thrive at their job, as well as the fundamentals to accomplish that job. Next, let’s compare the roles and responsibilities of a TPM to other roles that are often found adjacent to it.

Comparing adjacent job families

I love Venn diagrams because they show similarities and differences in a very concise and easy-to-follow way. Needless to say, you’ll see a few in this book.

A common question in my profession as a TPM is: what is the value of a TPM in a software team? The question is understandable because there is a lot of overlap between our job and the jobs of the roles most often adjacent to us in a software or hardware team.

We’ll start by exploring Figure 1.4, which shows the intersection of the roles most similar to the TPM, the PM, and the Product Manager-Technical (PM-T). Just as the TPM is a program manager that specializes in technology, the PM-T is a product manager that specializes in technology. The term PM-T may not be used at every company (just as TPM isn’t used everywhere) but the particulars of the job are the same:

Figure 1.4 – A Venn diagram showing the PM, TPM, and PM-T

The similarities between a PM, TPM, and PM-T are greater than their differences. The TPM, as a specialized version of the PM, shares the same skill sets and adds technical depth to these. The PM-T shares the same technical depth as the TPM, as well as with regards to organizing and prioritizing a roadmap, but specializes in the product roadmap instead of projects or programs.

In Figure 1.5, we’ll take a look at roles that are quite common to see next to each other, the TPM, Software Development Manager (SDM), sometimes called a Software Engineering Manager (SEM), and the PM-T:

Figure 1.5 – A Venn diagram showing the TPM, SDM, and PM-T

Although this diagram is a simplification of all of these roles, it does represent the typical alignments for these roles. The TPM shares a technical depth with both the SDM and PM-T and project management with the SDM. Most SDMs will run projects that are related to their domain or services, though they aren’t expected to be large or too complex from a project management perspective. To this end, they aren’t expected to be able to handle an entire program that lies completely within a PM or TPM’s realm of expertise. The SDM and PM-T can both create a product roadmap, and this is often a gap the SDM will fill when a PM-T is absent. Lastly, the PM-T specializes in product management and shares prioritization skills with the TPM. Simply put, at a pinch, these roles can often cover gaps in the team but given each role has unique skill sets – this would ideally only be short-term. For example, a PM-T isn’t necessarily needed for a small team with a single service, but as the team grows and the product becomes complex or begins to serve many diverse types of clients, a PM-T should really be brought on board. The same applies to a TPM – once the number of stakeholders becomes too large and complex, it begins to fall out of the expected comfort zone for a SDM and a TPM should be hired.

Wearing many hats

At this point, you can see that the TPM role has many functions. The Venn diagrams show that we overlap a lot with many adjacent roles. This unique overlap allows our skill sets to merge and fill in any gaps depending on the needs of our team. Over the course of my own career, I have found myself filling in the gaps of missing product managers, process managers, and even people managers by helping guide the developers in my projects.

This aspect of the job makes it extremely difficult to define the exact nature of what we do. The short answer is that we do it all. Our job is to ensure our programs and projects are successful and that may require different skills depending on the context of what is going on.

Even though this book talks about specific skills, they are not all in equal measure and can even change from team to team within a company! The needs of the team are often unique to what it is trying to solve or how mature the team is. The reason I have filled in so many gaps over the years is that the team I have been on has grown 10 times in size while I’ve been here. This means that at various times, the skill gaps or needs in the team at that moment have changed. In general, the more mature the team, the more defined your role in that team will be.

Now that we understand the functional aspects of the TPM role, and how that impacts how the job may manifest itself based on our team needs, let’s see how consistent this holistic view is across the industry.

Exploring functional competencies across the industry

I’ve worked for most of my time as a TPM at the same company – as such, I was concerned about an unconscious bias of what a TPM is or should be. To combat this, I sought outside perspectives from as many high-profile companies as I could – Amazon, Google, Meta, Microsoft, and Apple. To help confirm the interviews I had, and to fill in gaps where interviews weren’t possible, I combed through the job boards of these companies to see what each was looking for in a TPM.

I consolidated the interviews and job descriptions into a matrix in Table 1.1 that we’ll dive a bit deeper into. If something popped out to me as different in a particular interview or job post, I’ll call out what it is and why it’s interesting:

Normalized Level

Company

Qualifications

Education

Entry

Apple

SDLC

PM

CS or Comparable

Google

Align across multiple teams

PM/SDLC

CS or Comparable

Microsoft

PM/SDLC

Influence without authority

Biz Intel