E-Book, Englisch, 214 Seiten
Teter / Tobin Technical Program Manager's Handbook
1. Auflage 2024
ISBN: 978-1-80461-316-0
Verlag: De Gruyter
Format: EPUB
Kopierschutz: 0 - No protection
Empowering managers to efficiently manage technical projects and build a successful career path
E-Book, Englisch, 214 Seiten
ISBN: 978-1-80461-316-0
Verlag: De Gruyter
Format: EPUB
Kopierschutz: 0 - No protection
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.
Fachgebiete
Weitere Infos & Material
Table of Contents - Fundamentals of a Technical Program Manager
- Pillars of a Technical Program Manager
- Introduction to Program Management
- Driving Towards Clarity
- Plan Management
- Risk Management
- Stakeholder Management
- Managing a Program
- Career Paths
- Introduction to the Technical Toolset
- Code Development and System Design Expectations
- System Design and Architecture Landscape
- Enhancing Management Using Your Technical Toolset
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 TPM
- Learning the fundamentals
- Exploring what makes a TPM thrive
- Comparing adjacent job families
- Exploring functional competencies across the industry
Understanding the modern TPM
In the 1967 book, , 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 . As it turns out, Silverman’s book was one of the first books that used the term , 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 in the Oxford English Dictionary:
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!
shows the Google Books Ngram Viewer results for “Technical Program Manager” from 1955 through 2019 in the 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
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 , 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 , we will go into further detail on this.
Once you have a project plan, you will analyze the roadmap and identify any 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 – 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.
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...
