Comparing adjacent job families
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.
