Ask Aadil - Wrong way to use the TPM function
Ask Aadil - Wrong way to use the TPM function
What is the wrong way to use a TPM? How do you help fix the situation? Why does this happen?
This is a bonus post for all subscribers (paid and free). As always, you can reach out to me if you have questions about the role of technical program managers or the function itself at aadilmaan@gmail.com .
Question from Reader: I'd love to hear your perspective and takes on TPMs becoming glorified paper-pushers or Executive Assistants across all the functions we support, which is something I observe happening with some of the peers on my team.
That is a great question and something I will take a very long way to answer because I wish it was that simple.
Technical Program Managers operate on two planes:
🔭 Strategic — think 10,000ft view (week to week, month to month, quarter to quarter)
🔍 Tactical — think 100ft view (day to day, sometimes hour to hour)
Strategic work includes a number of things (in no particular order and by no means comprehensive):
Identify, monitor and resolve potential risks and road blocks that can derail programs.
Working with engineering leadership to determine the overall health of the program(s) and prescribe corrective measures.
Sit down and participate with frontline engineers to review a problem, work towards a solution and understand the impact this solution has on the overall program(s).
Work with Product Managers and the Product Leaders to understand what programs must be prioritized above others.
Work with the cross-functional leaders across product and engineering to decompose a desired outcome/program into a tactical execution plan (aka project plan).
Work with Executive leadership to develop a culture of effective execution (what we decide to work on, how we decide, what work needs the leadership attention to everything in between including processes and frameworks).
Work with Product and Engineering leaderships to setup, strategize, and execute executive reviews, meetings, and sponsor committees to ensure rapid decision making on strategic matters.
Tactical work includes a number of things (in no particular order and by no means comprehensive):
Backlog grooming
Issue management tracking + best practices
Setting up and driving engineering meetings + notes
Status Reporting
Information Architecture (keeping documents and wikis up to date)
Adherence to processes and frameworks
Sprint planning (if you are doing Scrum)
Run Steering committees?
🚨 The real value add of TPMs comes from being allowed to operate on BOTH these planes.
Why? TPMs will constantly weave between the strategic and tactical view throughout the product development lifecycle.
For every strategic decision there is a tactical outcome.
Ex: If we decide that the mobile UI redesign targeted to improve member onboarding is the right thing to focus on [strategic], we will need to ensure the work breakdown reflects accurately the work the cross-functional team needs to do in our issue management tool (think: epics + tasks etc) [tactical]. To do that, we will need to understand how we are going to build what we need [tactical] and whether this will require new technologies, build versus buy decisions, address tech debt or add more, will be required [strategic] and what this means for other items on the roadmap [strategic] given how resources are being deployed [tactical].
Wooooweeeee…
Now, with this context set, lets address the question:
If the organization is looking for someone to focus on just the tactical plane or process best practice and not participate/execute on the strategic plane — you do not need a TPM and nor should you be using a TPM. You are effectively bringing in someone highly effective and then forcing them to walk only on one leg.
🚩 This is a very traditional project management model where the PjM sits in the center of everything and coordinating all project activities. This situation is hallmark of an organization who has heard about this cool thing called TPM and wants all their scrum masters or project managers to act like TPMs because somehow it will make them be more like the Apple and Google; yet they still want them to keep doing what they do today.
I know there are a lot of assumptions in my statement above but I am confident my conjecture is not that off the mark.
Now, even within my own TPM network, I know many TPMs who staunchly draw the line on certain tactical activities especially scheduling meetings.
Even I have a rule for product development teams that I work with that “You should never wait for me to schedule every single meeting nor I am the only one responsible for keeping the ‘Jira’ tickets up to date”. I ultimately care about the outcomes and their impact on the program.
Yes, the TPM must own scheduling executive meetings and big cross-functional check-ins however, why do you need a TPM to schedule a discussion between two engineers to discuss a problem.
So, how do you fix this situation?
1️⃣ Help evangelize the TPM role. It begins with helping your leadership team to understand what exactly is a Technical Program Manager and what value-add they bring to the table. I have written about the fundamentals of the TPM role that you can use to set the stage.
2️⃣ Is your culture right for a TPM? Think Product → Program → Project. If your organization is currently operating at Product → Project model then consider bringing in an experienced TPM Leader to help Executive teams (Senior, Product and Engineering) to start working towards the Product → Program → Project model.
3️⃣ Ease in the TPM Role; Win hearts and minds. Pick a large complex program and allow a single TPM to run it, end to end, on both strategy and tactical planes. This will give you a rough idea of what resistance the TPM will face working with teams used to traditional project management and give the rest of the organization to become accustomed to the TPM function.
4️⃣ Establish a Program Charter before you scale the TPM team. Paula Dieli has written a phenomenal book on how to build an effective Program Management Office and tactical advice on introducing the Program role at your company. Check out her book here. Her advise is to first establish the charter for what the program management role will be like at your company before you convert everyone into a TPM.
Hope this helps.
Until next time. 👋
-Aadil
How was this week’s newsletter?
If you enjoy and love reading what I write, perhaps you know someone who could also enjoy and love reading these essays and dispatches. Share this with your friends and colleagues and lets grow together. 🙏 ☺️ ❤️
You can suggest topics or questions for me to write about in the future. It could be something you are curious about or maybe something you're struggling with right now.
Excellent post. Short and sweet, easy to read and understand. 💡🙌
A TPM/EPM or a Senior Program Manager should not be taken for granted or "forced" to serve as a "Project Coordinator" or as a glorified executive assistant. He can, may or will schedule meetings but only the ones that he needs to. With modern day collaboration tools, even taking notes can be made a shared responsibility (I have been doing that for past several years). We also need to understand that things change drastically as a company grows from ~100 employees to 1000 employees.