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.

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.

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.

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.

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:

Table 1.1 – A functional comparison of job roles across the tech industry

As you can see in the table, across the industry, there are more similarities than differences in the TPM role. This was a bit of a shock for me, to be honest. We’ve all heard of specific cultural stereotypes for Google, Meta, Microsoft, Amazon, and Apple – however, when it comes down to their expectations for the functional side of a TPM, they’re close enough to call them equivalent.

The expected education, regardless of level, was pretty consistent with some sort of technical degree or equivalent work experience (EWE) being required. For qualifications, this varies somewhat based on the level, but the pattern is similar. At the entry level, the focus is on fundamentals such as the SDLC and basic project management. For industry hires, it’s the core of program management and stellar communication, and then the principal level is focused on impact and proven results.

Insights into the TPM life from interviews

One thing that this matrix doesn’t cover extensively is style, which I was able to learn more about from the interviews I conducted. So, let’s talk a little about those things that stood out here.

Of the companies I held interviews for, Meta (formerly called Facebook) was the youngest, having formed in the mid-2000s. Due to this, their standards for project management are, as the interviewer put it, based on a “do what is needed” mentality. This is by no means bad, as many companies use this strategy to great success. There wasn’t much from the job boards that clues us in on this but the focus on the SDLC does seem to agree with the bottom-up approach to management that the interviewee referenced, where the drive is from the engineering teams.

At the other end of the tenure spectrum is Microsoft. I think a lot of people think about Microsoft’s own Project software and then lump it in as a highly regimented, PMP-style organization. As it turns out, this isn’t true! Though I am sure some people use Microsoft Project there, it isn’t standardized. The interviewee I talked to said many of the individuals they’ve worked with use Excel! Also, due to their tenure in the industry, they pre-dated the TPM job role and therefore mainly use the PM role title. Some organizations are starting to use the TPM role, both as seen on the job boards and also confirmed in the interview – the TPM title, and the matching compensation and requirements, are starting to be used in place of the PM title in areas that require technical expertise.

I’ve heard many people suggest that the TPM role originated at Amazon and that does make some sense. Back in 2013 when I interviewed at Amazon, I had to ask what the TPM role involved, as I had never heard of it! A quick internet search didn’t turn up any results either. But through some discussions, and simply looking at the timelines, you can see that the TPM role pre-dates Amazon. I wouldn’t be surprised if it was one of the first to widely use the job role based on conversations internally and externally, but it is hard to say for sure. Amazon is also a “do what is needed” organization, where the TPM role can vary quite a bit from team to team based on the gaps and needs of the team.

An interesting takeaway in my discussions about Google is that they are heavily product focused. A good portion – up to 30% – of the TPM’s schedule is dedicated to working with product managers on the product roadmap and backlog grooming based on the roadmap. The job descriptions hint at this as well when they discuss that Google is product-focused and how cross-team communication with engineers and product managers is a must.

Lastly, we have Apple. As it turns out, Apple doesn’t allow interviews with current employees about Apple life, so for this iteration, we only have the job descriptions. However, one interesting takeaway is that they are the only company (of those that I researched) that lists having a Project Management Professional (PMP) certification as a desirable (as in nice to have, but not required) skill to have.

A quick look into the main TPM career levels

Now that we’ve discussed different job families, let’s dive a little closer at the TPM role itself across the life of your career. Table 1.2 looks at the different levels of a TPM – entry, industry, and principal.

Table 1.2 – The TPM progression through three job levels

These terms are not standardized, but they still line up well with the various levels that I’ve encountered in my research for the book. The entry level means being 0 to 3 years out of college, and the scope and expectations are focused more on the fundamentals of the job. Industry level means 3 or more years of experience in the industry with no hard upper cap. This is the most common row with the largest growth curve. You go from a relatively new TPM with a basic understanding of the role and expand into mastering your domain. This is often the highest level of your career as a TPM, as most either stay at this level or transition to other job families. The last level that is common among these top companies is the principal level. Often this is the highest level achievable as a TPM across the industry, which puts you at the same level as directors or senior managers. However, this means the expected scope and impact are also at the same level as those directors, making this level more difficult to achieve – though certainly not impossible!

Now that we know what the TPM role looks like across the industry as well as the various levels, let’s see how consistent this holistic view is across 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. Next, 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 this chapter and dive deeper into the program management and project management strategies that help make us successful. Lastly, we’ll cover the technical nature of our role and how it feeds into the program management skills and techniques. Just as with the foundations found in this chapter, the pillars we discuss in Chapter 2 will be built upon and referenced throughout the book.