Because I’m tired of explaining what a Technical Program Manager does.
“So… you manage projects?” (Yes, but that isn’t all I do.)
“Are you a Product Manager?” (No, but I partner with them.)
“Oh, you’re the one who schedules the meetings and takes notes!” (Sometimes, but that isn’t the whole job.)
Things people have asked me time and time again. And while each of these has a sliver of truth, none of them quite capture what I actually do as a Technical Program Manager (TPM).
Throughout my career, I’ve had to explain to many people what a TPM is. I should have written this post a long time ago. It would have saved me a lot of time feeling like a broken record.
I’m writing this now because we recorded a podcast episode about the value of program managers, and one of the takeaways was we need to be our own advocates. We need to educate others and toot our own horns about the value of What We Do. (Podcast plug: If you don’t already know… I’m the co-host of The Messy Middle Matters podcast!)
So here goes!
The TPM role is one of those jobs that’s hard to define, but easy to recognize once you know what you’re looking for. We’re the people asking the right questions, aligning the moving parts, and making sure ideas actually become real things. We translate vision into executable plans, connect technical and non-technical stakeholders, and make sure nothing falls through the cracks. We are the connective tissue, the glue, the duct tape, sometimes the bare hands holding it all together.
We usually don’t write the code (TPMs at some orgs write code, but please don’t ask me to code), and we aren’t the final decision-makers, but we ensure the right conversations happen at the right time, with the right context. We turn ambiguity into clarity, chaos into flow. And when things change (because they always do), we “herd the cats”, assess, reorient, and keep the momentum going. One of the questions I ask the most is “What are the next steps?”
Depending on the team or company, a TPM might be responsible for driving cross-functional initiatives, managing end-to-end project delivery, aligning priorities across engineering and product teams, or setting up processes to scale execution. Unofficially, we may be a backup people manager, the team’s therapist, or the person everyone messages when something is on fire and no one knows where the extinguisher is. Sometimes (oftentimes!) it’s all of the above. The role sits at the intersection of strategy and execution, requiring both systems thinking and high emotional intelligence.
Because I love a good metaphor… if engineers are the musicians and the product manager is the composer, a TPM is the conductor. We don’t play the instruments or write the music, but we make sure everyone comes in on time, stays in sync, and plays at the right tempo. It’s the difference between sounding like music and sounding like a hot mess.
TPMs live — and thrive — in the messy middle (podcast plug #2!). We zoom out to the big picture, then back in to unblock a ticket that’s stalling progress. We write project briefs and define milestones, but we also notice when morale is dipping or when two teams are misaligned. We help organizations scale by creating structure where needed, but not so much that it gets in the way of speed.
It isn’t flashy work; in fact, most great TPMs I know actively avoid the spotlight. You won’t see our work in a demo or a release note. But when it’s missing, people notice. Deadlines get fuzzy. Teams lose focus. Communication breaks down. Accountability disappears. Everyone’s busy, but somehow, nothing’s moving forward. There’s a lot of motion but not a lot of movement. (I can’t take credit for that last line; I heard someone say it in a meeting, and it hit.)
At its best, Technical Program Management is a leadership role — not through direct authority, but through influence, clarity, and trust. It’s about creating the right conditions and empowering teams to do their best work together. And that means understanding how things work (and don’t), what people need (and why), and how to gently (but persistently) drive momentum.
TPMs are also really good at adapting. The shape of the role shifts based on the maturity of the organization, the makeup of the team, and the organization’s goals. It all depends on what problems the organization is trying to solve.
Early-stage startup? Building processes from scratch. Mid-stage scale-up? Connecting the dots across siloed teams. Large company? Translating strategy into coordinated delivery across multiple layers of stakeholders, usually across the entire organization, both wide and deep.
So when someone asks me what I do, I say some version of this:
I get shit done. I empower teams to do their best work. I connect dots. I make complex ideas a reality by aligning people, untangling dependencies, and adapting to whatever the work calls for.
It’s the work that makes the work… work.
If this post was helpful for you, and/or would be helpful to someone you know, I encourage you to share it far and wide!
And if you were like, “wow, that was so insightful, I’d love to buy Amanda a coffee!”, you can do that through Ko-fi 🙂
