15 Things You Should Know About Technical Program Managers

Becca Bruggman
Mar 12 · 8 min read
A selection of the hats I wear each week.

People often confuse Product Managers and Technical Program Managers (TPM). After reading John Cutler’s viral piece on Product Managers, I wanted to help elucidate how Technical Program Managers are similar to Product Managers, but also how they are different.

So what is a Technical Program Manager? It’s a nebulous role. One that I’ve realized not a lot of folks know about broadly or what we do specifically.

If you are curious about what TPMs do all day — perhaps you’ve seen them around your company facilitating a lot of meetings and speaking at company all hands or you have no idea how they are different from Project Managers — keep reading below.

Table of Contents

  1. They are the mortar between the bricks
  2. They have connections in every part of the organization
  3. They are the trusted advisor to their executive sponsor
  4. They have to be comfortable with talking about (and selling) their program all the time
  5. They have to assume no one knows about their program
  6. They must lead without authority
  7. They save their opinions for only the most important decisions
  8. They know not to expect any credit
  9. They have to be a utility player
  10. No two days look the same
  11. They will probably have a quarterly arts and crafts project
  12. The job is never ending
  13. They are actually technical
  14. It can be lonely in the middle of it all
  15. Programs without friction don’t usually need program managers

In an ideal world, Technical Program Managers are there to allow their coworkers to better focus on their core work. That means removing the need for them to think about agendas, scheduling, escalation to leadership, sharing status, understanding the whole system for risk assessment and ensuring enablement of customer-facing teams happens.

But in the real world, TPMs often have to play both bricks and mortar, especially on longer programs. More on that later.

Programs frequently have TPMs because they work across teams and having a single team owning the outcome would be difficult and imbalanced. As a result, TPMs need trusted advisors across all parts of the business. If there is a part of your program that now has a dependency on sales — do you know someone who has the right context and visibility to give you the guidance you need? If not, you may get caught flat-footed and uncertain if the advice you’re getting is complete.

Finding these trusted advisors can take time and why it can be hard to start at a new company as a TPM. If you’re still seeking an advisor in one part of the organization, look for people who are making their work visible via presentations and emails status updates. These people are already thinking cross-functionally and would likely be a strong starting point.

Executive sponsors for programs are also busy executives getting pulled in a lot of directions and are asked to attend a lot of meetings. Knowing when their executive presence is actually needed in person versus being able to recap status, parse out exactly where their opinion is needed and where you can handle continuing to move the program along is a combination of art and science.

Executives get pulled in a lot of directions and on to more urgent items. If your program is running successfully without them, this is a good sign because your program is not the most urgent or chaotic thing on their desk. Especially with programs with longer timelines, expect to become your own executive sponsor. That said, keeping things moving forward when you don’t have the executive muscle can be very difficult and frustrating. Knowing when to use your limited executive muscle and escalation time will be especially critical the longer your program goes on.

When you’re a TPM, there will be days when you hear “no” 17 times in the morning when asking for help or support with your program and you still have to present in front of your company in the afternoon.

When presenting, you’ll need to be energized when sharing status and progress for your program. If you’re not delivering your status and updates with confidence and energy, you’re fueling the cycle of “no” as no one will be enthusiastic about contributing.

At any company, there is a lot going on at any one time. People are very focused on their own efforts and what’s immediately in front of them. Additionally, your program is likely not top of mind for them. If you have not set up a cadence for sharing updates, do it right now. If you haven’t spoken about, sent a slack update or sent an email update about your program in the last 2 weeks, people probably have no idea where your program stands and have lost interest.

A rule of thumb that I live by is that unless people see you walking up to give a presentation and everyone is thinking “This person again? I already know everything they are about to say.” You are not speaking about your program enough.

Finally, don’t create new meetings to share updates. Don’t create new processes. Leverage meetings that already exist and get on the agenda or, if needed, just start showing up to ask questions and see where there are overlaps.

TPMs do not hold executive level titles. They cannot set quarterly goals for people. They can’t require that anyone to come to a meeting. Authority to mandate work or goals is always “above their pay grade.” They have to rely on a blend of political capital, charisma, and the ability to inspire others to get things done.

If you weigh in on every decision point, you’ll hit decision fatigue and “no” fatigue by lunch on Monday every week. You want to save your energy so you can intervene when it really, really matters. A northstar for being a TPM should be to have as few opinions as possible. You are reporting facts. You are identifying risks. Though often difficult, you should aim to deliver information without your own opinions layered on top as much as possible. Additionally, you’ll be in a lot of meetings for your programs and usually not considered the expert or having enough context for your opinion to hold much weight.

If you want a role where you get to be very opinionated and that is valued, I’d recommend you consider Product Management.

As mentioned earlier, TPMs are the mortar and not the bricks. You are reporting status and keeping things moving along, but often not doing the core work. It’s not the glamorous work, it’s not the work that gets the highest of fives, but it is the work that allows for programs to be delivered on time and at the best quality. That said, no one gets into Technical Program Management for the glory.

As programs move along, I often become evangelist, doer, and controller all at the same time. Executive sponsors will come in and out. The team you originally had will get pulled onto new efforts. You won’t get time and buy-in for dependencies you have on other teams. You need to be able to unblock yourself and also know how to escalate to your executive sponsor if you’re totally unable to. That said, the best TPMs are like swiss army knives. Having an interdisciplinary background is especially helpful here.

If hitting a goal with your name attached to it requires you to manually do work that your engineering team should really build a script for — you make time for that manual work. Your team needs some lightweight development work to unblock them — you take a first pass and ask for just time for a code review from your engineering team.

Blockers are where creativity and moxie matter the most.

Below are screenshots from my calendar for last week. Between running multiple parallel programs with different stakeholders, managing dependencies arising at different times and still trying to occasionally have focus time — the days can be quite variable. I know that in a month, this will look entirely different because some programs will have accelerated and others will have stabilized. I have to be pretty aggressive with scheduling my calendar with “WERK” focus blocks, otherwise I’ll never have time for larger projects, like writing blog posts :)

You must make the work visible. The easiest way to encourage hallway conversations and ongoing updates to your program is to grab the nearest rolling whiteboard or wall space in a high traffic area. Create a space to share or track status. So, get out the index cards, get the whiteboard markers, get the magnets with people’s faces on them, get the 11 x 17 print outs and start crafting!

Programs are a living organism. They are growing, evolving and changing constantly. You will discover new dependencies along the way that you never could have anticipated on day one. Being adaptable and able to continually identify those risks and new dependencies early and often is the only way to keep programs running smoothly.

TPMs have to understand their domain area, which often involves very complex, technical implementations. Knowing how to identify the blockers early and often without needing someone else as a technical translation layer is critical to unblocking programs and ensuring risks are properly mitigated. Additionally, doing program reporting often means going into complex data warehouses to write lengthy SQL queries. Knowing how to do this reporting for your program is important as your Business Systems team is unlikely to prioritize your reporting requests.

TPMs are interacting with people across the entire organization day-in and day-out, but that doesn’t mean that any of those people are their true teammates. We all meet in a room, talk about our programs and then everyone else leaves and goes back to the teams they actually sit on to find empathy in their shared professional struggles. TPMs have a hard time finding this sort of camaraderie and shared understanding, even with other TPMs. Each TPM is working on different programs with different stakeholders and different problems. As a result, you’re often a team of one and have to cheer yourself on.

If you’re not hitting friction frequently, your program is either not complex enough, very short-lived or some well-funded, top-level initiative that exists only in my dreams. A core belief of mine is that if a program was super well scoped, only sat with a single organization, had no chance of having scope creep and had complete executive buy-in — it does not need a program manager. TPMs are added to programs that are in chaos or have high levels of complexity. Expect the programs you get added to be worthy of being marked “RED” across the board when you get involved. That’s good. Seek that. It’s where you’re needed and where growth happens.

If you’re a TPM yourself, let me know if this rings true for you and hopefully this can be used as a resource moving forward when people ask, “So, what do you do?”

Questions? Comments? Divergent opinions? Comment below or tweet me at @bexcitement.

Becca Bruggman

Written by

Experimentation Program Manager @Optimizely || @UCDavis & @Hackbright Alumna || ❤️ Exploring, Fashion and Laughing Loudly