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 the sole purpose of achieving the program goals, and it 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 or goal! Once the task is complete, the computer program will terminate. Computer programs have evolved in complexity since their early days, as has the TPM, but the origins have a clear connection in meaning and purpose.

I found Mr. Silverman’s book while attempting to uncover the origins of the TPM role. What transpired during this research is that the usage of TPM had a similar evolution to the word program. The term went from a generic use to a more specific...

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.

The first terms to discuss are project and program. There are some companies where the “P” in TPM actually refers to “Project” instead of “Program,” and this can lead to some confusion. We’ll cover it in greater detail in Chapter 2, Pillars of a Technical Program Manager, but suffice to say that a program comprises multiple related projects. A project manager may run more than one project at a time, but they may not have a common goal. A program manager runs multiple projects that share a common goal and possibly multiple programs too. With that, let’s tackle some of the key management areas that are common between project and program managers...

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

Keeping forward momentum

For a TPM to thrive, their focus needs to be on moving the project forward and unblocking their team to get things done. This may sound like a cliché, as though you are reading it from a job description, but it is resoundingly true. Our innate drive to solve roadblocks, build a plan, mitigate risk, and drive toward deadlines are key to a project’s success. It is important to keep momentum on a project because, without it, we risk losing progress and need to start over. Context switching is often to blame here because, during the time a project is blocked, the individuals working on it may...

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? The question is understandable because there is a lot of overlap between our jobs and the jobs of the roles most often adjacent to us in a software or hardware team.

We’ll start by exploring Figure 1.5, which shows the intersection of the roles most similar to the TPM: the Program Manager (PM), and the Product Manager – Technical (PM-T). Just as the TPM is a program manager who specializes in technology, the PM-T is a product manager who 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 as they relate to our discussion are the same:

Figure 1.5: A Venn diagram comparing the TPM, PM, and...

I’ve worked for most of my life 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. I interviewed TPMs from these organizations and 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 pops out to me as different in a particular interview or job post, I’ll call out what it is and why it’s interesting. Since the industry hasn’t settled on a normalized level guideline, I created a three-tier leveling for the sake of brevity. The table covers positions that accept university graduates, which not every company supports. The industry...

In this chapter, we discussed the fundamentals of being a TPM. We started by explaining where the TPM overlaps with the generalized PM and program management and touched on the bare fundamentals for the technical aspect of our specialization.

Then, we examined the TPM role specifically to see what makes us thrive and found that drive, clarity, and being a communication bridge set us apart from our colleagues. Then, we expanded our view to look more closely into how our specialties overlap with the job families around us and across the industry.

We’ll continue to build on these fundamentals as the book progresses and, as we dive deeper into these topics to get a solid understanding of our role, how to be the most successful at the job, and how to progress your career the way that fits your skills and desires best.

Next, in Chapter 2, we’ll discuss the building blocks, or pillars, of the TPM role. We’ll build on the fundamentals we tackled in...