A TPM and a Staff Engineer walk into a bar
A conversation about the role of technical program manager and how it completes the role of the staff engineer
When it comes to technical leadership roles, Staff+ Engineer and Technical Program Management have one thing in common: confusion!
Outside big tech, these roles are still new and to be introduced.
wrote about the TPM back in 2022 and Staff Engineer just a month ago.I wanted to reach out to a veteran TPM who has had the role at big tech and exchange notes.
Drum roles please🥁Introducing
. 🎉
Aadil is a Sr Engineering Program Manager at Humane. He started his TPM career back in 2010 at Blackberry. In 2012, he moved to Apple as an Engineering Project Manager. 5 years later, he moved to Google as a Program Manager and 2 years later, joined Nike as Program Director. Eventually Aadil landed at Humane where he is currently working as a Sr Engineering Program Manager since 2021.
Aadil has been a lead TPM on both hardware and software programs of all sizes, worked on backend and frontend projects, even a programming language; his career theme is focused on 0 to 1 for large cross-functional programs. He is a big believer that humanities and technology go hand in hand whether it is his career as TPM or finding new programs and companies to work at.
He writes the
newsletter to demystify the Technical Program Manager role and how it can be a force multiplier when implemented the right way.The idea is simple:
List some interesting questions
Answer the same questions
Post the answers to each other’s newsletters (here’s my answers)
The goal is to give a bit of exposure to each other’s audience about what the other role is about, what are the challenges and opportunities for collaboration and how the two roles complete each other.
Could you give an elevator pitch for what Technical Program Management is about?
A Technical Program Manager is responsible for driving the execution of large complex cross-functional programs working in conjunction with Product, Engineering and Design as well as any number of other non-tech roles critical to the program. Moving between 10,000ft level and 100ft level, TPMs are the nervous system of the product team helping product and engineering to manage risk, ensure effective communication, drive dependencies and much more.
What are the most common confusions about Technical Program Management?
There are two points of confusion: how it relates to Product Manager, Engineering lead and how it is different from project managers and scrum masters. The role of TPMs is rarely seen outside of big tech, in particular the FAANG group. In early-stage startups, Product Managers will play both the product and TPM role or sometimes the TPM role is played by engineering leads.
What is the main value proposition for Technical Program Management?
A complex cross-functional program is composed of multiple teams, each with their own scope and goals, coming together to work towards a combined desired outcome. Product is focused on setting direction for engineering, engineering is focused on figuring out how to build the solution, design is focused on how to design it. At some point, naturally, it becomes difficult to keep things aligned across so many workstreams.
A Product Manager absolutely could be focused on this but remember that during the product development, things are constantly changing and the PMs themselves are trying to figure out the direction of the product and program. That is where the Technical Program Manager position comes into play. They are the nervous system that is plugged into every moving component, part, team of the program, constantly keeping an eye on the overall health and progress (schedule delays, new risks, blockers, missing requirements, gaps etc.).
They are constantly evaluating with a system thinking mindset where optimizations can be made to improve the effectiveness of cross-functional teams. This can be as simple as should we do 2wk or 6wk sprints to no sprints and focus on milestones to communication strategy, document artefacts, or what format to track work.
What separates the TPM from other traditional project management roles is our systems-level understanding. We can dig deep into issues with engineers and find dependencies that can be overlooked because we don’t operate so much in the weeds of things. Staying at a program level gives us a perspective not afforded to individual teams on a cross-functional program. TPMs are effective when the organization hits a certain size or the opportunity cost of product or engineering taking this role is too expensive regardless of company size.
What is the difference between the TPM and Staff role?
The biggest difference is that Staff can make decisions while the TPM can only influence. TPMs are leaders without formal authority. We lean on the Staff and Engineering lead to help us to influence the direction of the program towards the desired outcome especially when a risk is causing us to drift.
You have the TPM who is looking at the decision the Staff engineer is driving towards and quickly assess whether there are any domino effects on the schedule and/or other teams both technical and non-technical.
A Staff engineer could absolutely do this all, but wouldn’t you rather have them focus on the engineering aspect rather than working with every other team to assess the schedule or dependency impact. Opportunity cost is how I tell everyone to assess a TPMs role in an organization.
Both Staff and TPM execute the strategy. Staff works with or in many cases provides the bulk of the brains behind solutions. The TPM supports the Staff in understanding the resourcing required, asking questions about potential risks, developing artefacts, effectively taking the Staff Engineer’s solution, and turning into a tactical execution gameplan. This is everything from overlaying all the moving pieces that every team will deliver in some dependency mapping format (aka Gantt chart) to communication of how we will address the progress of the project.
What’s the best part about Technical Program Management?
The ability to move from 10000ft to 100ft and back up is perhaps the best part of this role. The learning you are able to achieve across so many disciplines as a TPM is unbelievable. Operating at a systems level is such a treat.
What’s the worst part about Technical Program Management?
Leading without authority – TPMs have no formal decision-making powers. They are leaders without any authority.
We must constantly influence and nudge the powers to push the program in the right direction. The worst part of it all is you don't get to win every battle. You just make your peace with it.
For many TPMs, especially new ones, this is the hardest aspect of the role to get over. It requires sharp soft and organizational development skills. These skills unfortunately come from years of experience and failure.
How deeply do you need to understand the tech to be able to do your job effectively?
Deep enough to be effective, which for me means holding your own against engineers in technical conversations.
The best way to explain this is a simple test: can you take a functional engineering requirement or workstream and explain it to a business leader of what and why it would take this long to ship this.
When a lot of engineers see the Technical Program Manager title, oftentimes they assume we are just a fancy type of project manager who has no idea about how the technology stack and modern apps (web, mobile or desktop) are built.
I always recommend that as a TPM you must have a systems level understanding of how backend and frontend come together to enable magical experiences to happen, whether that is a SaaS application or fancy new mobile app or even an internal tool.
How do you keep up with technology?
Read, always be reading. Whether that is blog posts, newsletters, books, always be reading.
Every day I take time to hit up hacker news to see what weird technology trends people are fighting over. Many times, I have come across wonderfully curious topics to deep dive into and probably my biggest driver of new tech trends.
I find great thought leaders and writers on twitter and through newsletters.
I have found many great recommendations through communities like Lenny’s Slack community.
Ultimately, my goal is that at any given time my knowledge is out of date so the thirst for new knowledge must always be constant.
What kind of AI will deprecate Technical Program Management?
I don’t know if I can answer that question. Partly because I don’t know where the AI is going in this particular space where the role is more human interaction based.
I think someone will make GitHub Copilot equivalent for traditional project management, but the human interaction part will still be tricky. A big part of my role is people and working with people. Until AI can have empathy and soft skills, I think TPMs are fine.
What are the other roles you typically interact with and how?
The two primary roles that a TPM will interact with are product and engineering.
Depending on how the organization setup and culture, design may be another role that TPMs work with. TPMs are constantly taking discussions, requirements, and strategies developed across these three functions and synthesizing execution plans including when the right time is to feature complete, code complete, production ready, when do we test, when design needs to lock down things, what requirements still need to be fleshed out by product, when certain risks are becoming showstoppers.
I keep repeating this mantra: TPMs are the nervous system that keeps these teams connected while they focus on executing on their scope of the project.
What kind of person thrives in Technical Program Management?
Someone who is extremely comfortable with ambiguity and has a profound sense of empathy. In modern product development organizations, we often design, build, and fly airplanes at the same time. It is hard to develop tactical strategies when things are uncertain.
There is no point in sharing dates when so many details are evolving, or uncertainty is high. I have seen many TPMs burnout when the ambiguity is too much to handle, or they prefer a more regimented and structured environment. In these uncertain environments TPM who thrive knows when to stick to the rulebook and when to just throw it out the window and fly by the seat of your pants.
When does a company know that it needs Technical Program Management? When is it fine to use other roles that overlap in scope and responsibility?
In early-stage startups, this role is typically played either by engineering managers/leads or Product Managers. However, when a company hits the growth stage is when the first inklings appear of a dedicated function like TPM will be needed. Even then, it is an opportunity cost conversation.
TPMs should never be mistaken for scrum masters or someone to manage the Jira backlog. They specialize in cutting across business, product, and technology teams to understand what is needed by when to deliver large cross-functional projects. If your Product Manager can do that, then you don’t need a TPM.
If your Product Manager is spending more time working with engineering to focus on what to ship right now versus what engineering needs to focus on next (which could be next week, next month, or next release), probably time to start exploring TPMs.
What is your methodology to self-onboard when you’re new to a domain?
If I have a TPM that I am replacing, I shadow them for the first two weeks.
There is this instinct in many TPMs to come straight in start proposing process changes and pumped up to set up new meetings etc. I have done well over time to suppress that urge and instead learn how the previous TPM worked or how the product team works.
I observe the culture of the team (written and unwritten) and along the way I ask questions and learn as much as I can from the senior folks about how the domain is set up and the technologies within it.
My goal for the first 30 days is to become well versed in what the team does, the area they support, how they do work, how they make decisions, the stakeholders, what meetings matter etc. By the 60-day mark I should be comfortable with representing the teams in cross-functional conversations. By the 90-day mark I am looking at opportunities for improvement and starting to drive things in a manner I see fit with close collaboration with my product and engineering partners.
What does your average day look like?
It varies by the week. Much of my work is discussions and collaborative work sessions aka meetings. A typical day may consist of engineering syncs, staff meetings, 1:1s with various people and oftentimes ad hoc meetings to resolve the fire of the day. To put it simply, I am oscillating between firefighting, waiting, watching, and planning throughout the week.
What path do you recommend to people who want to grow into Technical Program Management?
The best writing, I have seen so far on the topic of Program Management in the tech industry has been Get on Track by Paula Dieli. It's a great primer on program management in general. The other source I recommend is Will Larson’s System Engineering Management book. Gergely Orosz has written perhaps the best primer specifically on TPMs in the industry - I recommend it to everyone who's curious about the basics of the role.
I also wrote extensively about the basics of the TPM role with Luca Rossi for Refactoring newsletter which you can read here.
How do people contact you and follow your work?
You can find me on LinkedIn, Twitter, Substack or email - aadilmaan@gmail.com.
Conclusion
I hope you enjoyed reading Aadil’s answers. 🙌 Don’t forget to check my answers to the exact same questions on his newsletter!
 | A guest post by
|