There are moments in a program management career where the numbers stop being abstract and start being very, very real.
For me, one of those moments was at Asurion, when I was brought in to lead a transformation of the back-end systems running the company’s automated logistics and shipping operations. The problem was framed clearly: when these systems went down, the company was losing $1.5 million per day in EBITDA exposure.
I want to sit with that number for a moment, because it’s easy to read past it. $1.5 million. Per day. Every day the system was degraded, that was the cost. Not projected cost. Actual, measurable, accounted-for revenue impact.
That’s not a technology problem. That’s a business emergency dressed in a technology costume.
The First Thing I Did Was Stop Talking About Technology
When you walk into an environment with that kind of financial exposure, there’s a temptation to immediately start diagnosing the technical root cause. And you need to do that — but it can’t be your first move if you want to actually solve the problem.
My first move was to understand the business impact model. Which systems were revenue-critical? What was the cascade when they failed? Who owned the decision to take on risk during a remediation window? What was the tolerance for controlled downtime vs. uncontrolled downtime?
Those answers shaped everything that came after. The technical work was real and complex — back-end systems that had grown organically, integrations that nobody had touched in years, infrastructure that had been patched rather than redesigned. But the technical work had to be sequenced and scoped in a way that the business could absorb.
The Transformation Itself
What we built was a more resilient, observable, and maintainable version of what existed — not a wholesale replacement, which would have introduced more risk than it resolved, but a structured modernization that addressed the specific failure modes that were costing money.
We reduced overall downtime by 80%.
That’s a number I’m proud of, but I want to be clear about what it represents: not just better uptime, but better decision-making. Clearer ownership. More observable failure modes. Faster recovery times. A system that, when something went wrong, told you what was wrong instead of just going silent.
The technical outcome was real. But the organizational outcome — the shared understanding of what these systems did, who owned them, and how to manage them — was equally valuable.
What High-Stakes Programs Actually Require
I’ve been asked what it’s like to work in environments where the financial stakes are that high. The honest answer is that it sharpens everything.
It sharpens your prioritization — you can’t chase every issue when every day of instability has a price tag. It sharpens your communication — you can’t hand-wave technical complexity to a leadership team that’s watching the number every morning. And it sharpens your honesty about risk — you can’t afford to be optimistic about timelines or capabilities when the cost of being wrong is measured in seven figures.
High-stakes programs also reveal something else: how an organization’s culture performs under pressure. At Asurion, I had leadership that was willing to make hard calls when presented with clear options and honest tradeoffs. That made the work possible.
I’ve worked in environments where that wasn’t true — where escalation was avoided, where bad news was softened until it was too late to act. Those programs are harder, slower, and more expensive. Not because the technical problems are bigger, but because the decision-making environment doesn’t support solving them.
The Lesson I Keep Coming Back To
$1.5 million a day gets people’s attention. What you do with that attention is the real test.
You can use it to generate urgency without direction — a lot of activity, a lot of noise, not a lot of progress. Or you can use it to create clarity: here’s the problem, here’s the model, here’s what we’re trading off, here’s what I need from you to move forward.
The first approach keeps everyone busy. The second approach gets things fixed.
I’ve always preferred the second one.
High-stakes programs reveal how an organization’s culture performs under pressure.
If your program has a number like that attached to it — and more do than people openly admit — the most valuable thing a senior TPM brings is not technical expertise. It’s the ability to turn urgency into structure, and structure into outcomes.
That’s the job.