Search icon
Subscription
0
Cart icon
Close icon
You have no products in your basket yet
Arrow left icon
All Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Newsletters
Free Learning
Arrow right icon
Technical Program Manager's Handbook

You're reading from  Technical Program Manager's Handbook

Product type Book
Published in Dec 2022
Publisher Packt
ISBN-13 9781804613559
Pages 214 pages
Edition 1st Edition
Languages
Author (1):
Joshua Alan Teter Joshua Alan Teter
Profile icon Joshua Alan Teter

Table of Contents (19) Chapters

Preface 1. Part 1: What is a Technical Program Manager?
2. Chapter 1: Fundamentals of a Technical Program Manager 3. Chapter 2: Pillars of a Technical Program Manager 4. Part 2: Fundamentals of Program Management
5. Chapter 3: Introduction to Program Management 6. Chapter 4: Driving Toward Clarity 7. Chapter 5: Plan Management 8. Chapter 6: Risk Management 9. Chapter 7: Stakeholder Management 10. Chapter 8: Managing a Program 11. Chapter 9: Career Paths 12. Part 3: Technical Toolset
13. Chapter 10: The Technical Toolset 14. Chapter 11: Code Development Expectations 15. Chapter 12: System Design and Architecture Landscape 16. Chapter 13: Enhancing Management Using Your Technical Toolset 17. Index 18. Other Books You May Enjoy

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

CS or Comparable

Equivalent Work Experience (EWE)

Industry

Amazon

PM/SDLC

Remove ambiguity

Thought leadership

CS or Comparable

EWE

Apple

Leading a team

Established PM/SDLC

Communication

Strategy and Program Delivery

BS or MS

EWE

Google

E2E Delivery

System Design

Data Analysis

CS or Comparable

Meta

PM/SDLC

Works with other TPMs

CS or Comparable

EWE

Microsoft

Exp. Writing code

Defines program goals

PM/SDLC

CS or Comparable

EWE

Principal

Amazon

PM/SDLC

Remove ambiguity

Thought leadership

CS or Comparable

EWE

Microsoft

Proven PM

Strong technical proficiency

Excellent communication

BS/MS in CS or Comparable

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.

You have been reading a chapter from
Technical Program Manager's Handbook
Published in: Dec 2022 Publisher: Packt ISBN-13: 9781804613559
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at €14.99/month. Cancel anytime}