Why hire Technical Program Managers when we have Product Managers
Vol II 05/52: Do we really need TPMs to keep track of the WHEN if the Product Manager has a focus on the WHY & ensures high alignment through transparent & continuous communication? Yes & here's why.
Two weeks ago, I had an amazing opportunity to collaborate with Luca Rossi of Refactoring to talk about “What is a Technical Program Manager”. You can read the post here:
This article was shared on LinkedIn which sparked perhaps the most fascinating conversation I have had in awhile and perhaps the most important question as well about the role of Technical Program Managers:
Do we really need project leaders to keep track of the WHEN if the Product Manager has a focus on the WHY and ensures high alignment through transparent & continuous communication?
I mostly see that people in these roles increase meetings that mostly focus on status reporting, which adds work but not value. I believe that the need to have these roles come from the company not focusing on what is most important, that the teams don’t work towards common goals. Or that the organization has not been very successful in removing dependencies.
Are there perhaps too many top leaders driving work that trickles down to the same team/s - all saying ‘my is most important’?
This is such a great question + insight because often times the confusion around this topic stems from leaders only focusing on bringing Technical Program Managers as merely project managers or scrum masters disguised in a fancier title.
Perhaps, the best way to answer this question is with a real world example of where and how TPMs add value.
Problem with WHEN and where TPMs add value
Problem is WHEN is a tricky thing and it’s never settled until it’s shipped.
WHEN will react to new unknowns, new risks, new realities but the WHAT and WHY will rarely change unless the project duration is so long that external realities (industry) changes while you do your work (waterfall versus agile anyone).
Let me share an example from my career that may help illuminates things: Google’s first Visual Assistant devices in partnership with Lenovo powered by Android Things.
A 0 to 1 product like this has an insane amount of layering (engineering and business). To top it all off, you are also talking about building the product using a brand new platform - Android Things.
The hardware (HW) and software (SW) will have many layers and requirements.
HW certifications, HW components and partners, software certifications, quality and testing requirements, we are talking a full blown operating system, a full platform upon which it’s being built, new features and applications being designed from scratch, making them run on a new platform, new dev tools, oh lord, so much. Not to mention, HW and manufacturing will have their own build schedules and requirements for factory testing and validation.
Then, you add business development and marketing to the equation; they have their own plans and dates they are working with vendors and sellers, contracts with sellers to hold shelf space.
Now imagine if your chip vendor comes and says this bug will need 2wks to rework. You are at a critical milestone when this hits. This starts the dominos effect.
Does this have any impact on app and features being built?
What about certification? Does it hit both HW and SW certifications?
If this milestone moves out what about the rest of the schedule?
Do the business teams need to push things out?
What are the alternatives; Can engineering do something different to mitigate the risk?
What about the impact to the future HW revs? Does manufacturing need to shift dates for future builds?
Wait, what does this mean for our other teams; are they impacted by this delay?
How do we limit the impact of this change in schedule?
Do we need to discuss/escalate this with leadership?
Now, a PM could do all this…OR they could focus on making sure that the path for engineering is clear on what comes next, next milestone, next design drop, next feature meeting, next marketing strategy discussion.
That’s why a TPM is often added to keep an eye not on one aspect of a project or team but the whole grand picture. You could have two TPMs working in sync: one for hardware and one for software.
TPMs will highlight where PM and Engineering needs to pay attention because it means this for the bigger picture or schedule.
Today it was a chip issue, tomorrow it will be the mic not answering “hey google” at high enough pass rate. How do we fix it? Is it a software issue? HW component or Mic issue? Can we investigate and fix this without hurting the schedule? But what does this mean for the rest of the work that engineer is doing? Do we hire new people?
Maybe another time is software is not stable because we need more time to converge. Dogfooding is highlighting a ton of performances issues that requires us to re-evaluate our current architecture?
These are but a few real world examples I managed on a program of this scale.
At no point in the example above is the problem that the cross functional team is focused on the wrong goal, has communication problems, or terrible at communicating with each other.
Engineering by nature is chaotic, its is messy, its crazy, it has many moving parts.
Remember that with agile nothing is ever fully figured out. This is why it’s completely understandable when we say that if PMs are focused on WHAT and WHY, they should also be focused on WHEN and HOW. We assume in this statement that everything is figured out and we are just marching to a plan.
Does every org need a TPM? No.
Can PMs do the TPM work? Yes and they often do at early stage startups and growths companies.
At some point, as the org grows it becomes challenging to accomplish both the PM and TPM role by a single person. The first sign of that is actually communication problems, alignment issues, and lack of risk mitigation or response.
To hire a TPM and when to hire is first and foremost a matter of opportunity cost.
Eventually organizations need to trade off between objectives and goals, communication gets harder, middle management grows and gets distant from the work and it will get harder for PMs and even Engineering Leads to stay on top of the bigger picture. However, TPMs are absolutely not all about status and meetings only. As a matter of fact, we should be reducing and optimizing meetings not increasing them.
I hope this helps you further understand the powerful value add TPMs can be when brought in at the right moment and for the right reasons.
Much like a PM, a great TPM, well you will know when you work with them. It’s straightforward to say what a PM or TPM does on a job description and skills you require but it’s a different thing to experience a great PM and TPM.
Until next time 👋!
-Aadil
🤔 How was this week’s newsletter?