Let me tell you how most people describe my job when they hear the title.
“Oh, so you run meetings and make sure everyone’s on the same page?”
Sure. I also do that. And then there’s the rest of it.
I’ve spent 25 years leading programs that, if they went sideways, would take down hospital systems, halt shipping operations for a major logistics company, or interrupt services that millions of people use every day. The meeting facilitation is real. The stakes are what most people don’t see.
So let me clear it up.
The Real Job Is Managing Risk at Scale
A senior TPM’s core function isn’t coordination — it’s risk containment across complex, interdependent systems where failure has financial, regulatory, or operational consequences.
I’ll give you a concrete example. At Asurion, we had an automated shipping and logistics infrastructure that, when it went down, was a risk of $1.5 million per day in EBITDA. When I came in to lead the transformation of those back-end systems, my job wasn’t to “align stakeholders.” My job was to understand the failure modes deeply enough to redesign around them — and to communicate the risk clearly enough that leadership could make good decisions. We cut downtime risk by 80%. That’s what a senior TPM actually does.
Making Risk Legible
The single most valuable thing I do in any program is make risk visible before it becomes a crisis.
Not visible as in “I put it in a spreadsheet.” Visible as in: leadership understands what breaks, what the financial exposure is, and what decision they need to make in the next 72 hours.
There’s a difference between a status update and a risk brief. Most programs I inherit are full of the former. They tell you what happened last week. They don’t tell you what’s about to go wrong.
The gap between those two things is where programs drift into crisis.
Forcing Tradeoffs Into the Open
Every enterprise program is a negotiation between competing priorities. Speed vs. reliability. Scope vs. operational stability. Innovation vs. regulatory exposure.
The tradeoffs don’t disappear when no one names them. They just get made implicitly — by whichever team is under the most pressure that week.
My job is to name them explicitly, frame the options clearly, and force a decision before ambiguity compounds. Ambiguity is expensive. I’ve seen it cost companies months and millions.
Designing for Failure, Not Success
Here’s something that doesn’t make it into most job descriptions: I spend a significant amount of time thinking about how things will break.
Not because I’m pessimistic. Because in complex systems, something will always behave differently than expected. An integration that worked perfectly in staging will do something strange in production. A vendor will miss a deadline. A security rule will block access at 2 a.m. on the night of your cutover.
I’ve been at 2 a.m. more times than I’d like to count. What determines the outcome isn’t whether something breaks — it’s how small the blast radius is when it does.
Senior TPMs reduce blast radius before launch. That’s the job.
Bridging Engineering and the Executive Floor
Engineers think in architecture. Executives think in impact. These are not the same language, and I am fluent in both.
When I was at Vanderbilt University Medical Center advising on their Epic EMR implementation and Windows 10 migration for 22,000 endpoints, the engineering teams were focused on deployment sequencing. The executives were focused on patient care continuity. My job was to keep both conversations honest — and connected.
When those two perspectives align, programs move. When they don’t, you get delays, scope creep, and expensive escalations.
If a program feels easy, it’s either small — or risk hasn’t surfaced yet.
The role of a senior Technical Program Manager is not coordination. It’s controlled execution under uncertainty.
Now you know what I actually do.
This article is part of a broader perspective on Enterprise Technical Program Leadership across high-risk enterprise environments.