So, What is a Technical Program Manager (TPM), Anyway? Part 1: The TPM Triangle7 min read

Note: this is part one of a two part series. See part two here, which includes how TPMs and other PM roles fit together or in some cases, are redundant.

If you see my About page, you’ll notice that I am a Technical Program Manager (TPM). So uh, what is that? you might wonder. This post is the first of a series to define the role. As much as I would love to immediately dive in and start explaining the role, some initial context is required up front.

Imagine you are starting a software company; what is the first role you need? Engineers, right? As without engineers, your company isn’t actually a software company. OK, so you hire your first team of engineers – great! But wait – what are the engineers going to build? And how will they have confidence in this answer? Bam – right here, this is where organizations get complicated, as this question can be interpreted in a lot of ways. Business leaders will tell you this is about product-market fit, such as what customer problem(s) are we solving? Technical leaders will tell you this is about what technologies to leverage, such as whether to leverage an Amazon Web Service (AWS) or an open source technology. Design leaders will tell you this is about making a lovable experience, as in, what does the overall user experience look like? Which answer do you choose?

Without a conscientious approach across disciplines, organizations break down. Perhaps your company is small enough that you don’t experience this problem; perhaps you as CEO can fill this void directly. Great! But now let’s pretend you launched your product in your first year, and now it’s year two. You no longer have one engineering team, but four. Additionally, you now have a small design team, a small marketing team, and a small product team, each producing a different set of priorities. To top it off, you have investors, lawyers, and public relations to deal with. What do you do?

At a high level, what was described in this scenario is a classic organizational psychology problem that arises once a particular scale has been hit. Yes, you can attempt to solve this problem organizationally, such as with the Spotify squad model, but beware: Spotify has abandoned their own model due to failure. So, what’s another solution to this problem? Enter: Technical Program Managers.

Perhaps the leaders of different disciplines above are all making valid statements; it’s not that we want to choose one to listen to, but instead we want to span across them and produce a cohesive plan. You should choose priorities that have a good product-market fit, and use the right technology, and are a lovable experience. In other words, requirements across disciplines – in this case, product, design, and technical requirements – must all converge into the same plan. Depending on the project, there can be other requirements as well, such as legal or marketing requirements. The point is, when working on a project that spans multiple disciplines, or functions – often called cross-functional projects – you need a Single-threaded Leader (STL) / Directly Responsible Individual (DRI) to own the project. Having that leader separate from the involved disciplines minimizes bias in decision making.

But wait – why would we want someone who isn’t a subject matter expert (SME) making decisions on behalf of a discipline? You don’t. First and foremost, if a project isn’t cross-functional, you probably do not need a TPM, and they certainly shouldn’t be the single-threaded leader. Therefore, a TPM should never be making decisions about a single discipline in isolation. The only exception to this is if you need help cross-organizationally, for example, managing a technical project that spans multiple engineering organizations. A TPM may be helpful in this case, but it is unlikely to require a Staff or Principal level TPM to manage this project. Additionally, every time I have owned such a project (sometimes impacting 100+ engineering teams), there is some amount of cross-functional impact. For example, other functions need to know about the work to account for it in their priorities.

It is also important to note that in cross-functional environments, escalations of decisions still occur, so complete control of a discipline is not handed off to TPMs.¹ Oftentimes it is even the TPM doing the escalating! For example, if a project involves both a business and design leader, and they cannot agree on a plan, it is the TPM’s job to understand both sides and decide on the path forward. This usually takes the form of a documented decision, similar to an Architectural Decision Record (ADR).² However, if the decision is still not agreed upon, then it is escalated to managerial leadership across all involved disciplines until a decision is made. The documented decision is then updated (if needed), and the project continues. Simple, right? 😅.

I have heard many summaries of TPMs in my career, from “generalists,” to “breadth-oriented,” to “cross-functional specialists,” to “glue across an organization.” While true, I summarize TPMs as a Jack/Jill of all trades, master of none,³ where the trades involved depend on the context of projects, the organization, and the company.

OK, what if the cross-functional project doesn’t include engineering? Do we still need a TPM? Probably not; the word “technical” is simply an adjective on top of “program manager.” A non-technical program manager would likely be the best fit for cross-functional projects that are not technical in nature.

OK, but can we go a level deeper? As is a TPM just mediocre at everything? No single-line summary does an entire role justice. Like all roles, there are boundaries. And for this, I want to give credit to Jon Canan, a peer of mine at Zillow. I have chatted more with him about the topic of TPM role clarity in his first three months at Zillow than I have with anyone else in my entire career, let alone over an entire year. The following framework is primarily his and is better than what mine was before I met him. It is shared here with his permission.

Every TPM has some degree of aptitude in the following areas: 

1. Product Management – ensuring we are building the right thing.
2. Project/Process Management – helping the team/organization to operate effectively.
3. Technical Knowledge – supporting/leading the team through technical challenges.

All TPMs must be able to do all three of these, but most are strongest at only two; very rarely is someone great at all three, let alone all three at the same time. Together, these three areas produce vertices in what is known as “the TPM triangle,” and TPMs can plot themselves within it:

Plotting within the triangle is then a useful tool. For example, a TPM can plot their current strengths and preferences and share where they need to grow. I tend to plot myself in the following areas, depending on the project:

Given my background of a backend infrastructure developer, this shouldn’t be a surprise; I enjoy adding value by organizing technical efforts and helping to set technical direction. And when I am in roles that require different areas of focus, I may be happy working on areas of weakness to improve them, but I will not last indefinitely. Being able to share this with hiring managers has saved me headaches from getting into long-term situations that do not match my skillset or current career goals!

Similar to the value of TPMs plotting themselves, hiring managers can plot what they need with recruiters to help tailor candidates to the right roles. This creates the following archetypes, similar to those for Staff Engineers:

If you map these back to where I plotted myself above, you will now understand what TPM archetypes I fit into, and which I don’t. Again, you would be amazed out how this simple tool has helped me quickly weed out roles which are not a good long-term fit for me or my skillset! We’ve found such success with it at Zillow that now all hiring managers of open TPM roles must choose the preferred archetype for the role. This is shared both with interviewers and recruiters to help match the right candidate to the right roles, and occasionally, funnel candidates between roles where they are a better fit. If you are interviewing, you should use this tool yourself to cross-compare!

OK, how does a TPM work with other roles within the TPM triangle though? For example, how do a TPM and a Product Manager (PM) work together? Great question 😅 – this is what I will cover in my next post, which you can see here!

---

Appendix: Good External Resources of TPM Definitions

All of these references influenced my writing and deserve to be cited here. However, they are often in conflict with one another (yet I still argue they are recommended reading in aggregate). Thus, the opinions in this post are not a perfect match to any one of these, but you will see areas of agreement and conflict with this post if you read any of these.

1. Medium TPM Stories
2. Pragmatic Engineer’s Post about TPMs
3. The TPM Blog (Mario Gerard)
4. Steve Yegge’s Podcast about TPMs
5. Qualtrics TPM Tenets
6. Another Medium Blog post about TPM tenets
7. Tanya Reilly’s No Idea Blog: “Being Glue” – this one talks about engineers and managers being glue, but a lot overlaps with TPM, should an organization need the dedicated role

Appendix: Additional Resources as to Why it’s Valuable to Be a Comprehensive TPM

These are references that I found after writing this article that I feel justify why it’s important to avoid over-specialization in the field:

1. Why Generalists Own the Future: This post shares that with the rise in LLM tooling, being a generalist is all the more important.
2. When Your PM Drives you Crazy: Written from the perspective of an engineering leader, this post explains how a balanced partnership between your product and engineering leadership is the only sustainable approach.

---

Footnotes

1. Escalating a decision to leadership is simply a tool in the toolkit; it is not something to be afraid of! ↩︎
2. Of course, some documented decisions are non-architectural; ADRs are just an example process of keeping a paper trail of critical decisions. ↩︎
3. This value of this phrase is elaborated on in this excellent post by Gergely Orosz. To summarize, there is a debated second line to the quote: “Jack[/Jill] of all trades, master of none, but oftentimes better than master of one.” While I love this added line, Wikipedia summarizes that it is unknown as to whether or not it was originally included as part of the couplet. ↩︎