The Hot Potato Program: How to Rescue a Mess Without Losing Credibility
Practical strategies to fix a failing project—and keep your reputation intact
What would you do if someone handed you a hot potato? Hold it too long, you burn your hands. Drop it too fast, you look incompetent. That’s exactly what it feels like when you inherit a failing program.
You have two choices: hand it off to someone else ((if you can get away with it) or figure out how to cool it down—and maybe even enjoy it with your team.
I can’t tell you how many times I’ve thought, “Oh no. Not again.” Another program in chaos, with customers shouting, teams burning out, and leadership losing patience by the hour. Everyone wants results yesterday, and no one wants to own the mess. If this sounds familiar, you’re not alone.
I’ve had to navigate this dynamic more times than I care to admit. Most recently, I led the world’s largest implementation of Copilot Studio—a program that ultimately served over 15 million customers of one of Australia’s largest financial institutions.
Coordinating engineering, product management, sales, customer success, consulting teams, external vendors, and specialist roles was less about perfect frameworks and more about trust and disciplined prioritization.
No process document could prepare us for the reality on the ground. Only a structured approach to stabilizing and simplifying the chaos made progress possible.
Depersonalize the Problem
When a program is in freefall, the first instinct is to start identifying who failed to do their job. It feels productive to assign blame, but it rarely helps. All it does is harden defenses and create a culture of suspicion.
The truth is, most troubled programs don’t collapse because of one spectacular mistake. They unravel because dozens of small decisions, compromises, and overlooked details compound over time. What starts as a harmless “we’ll fix this later” becomes an existential risk when no one circles back.
If you can resist the urge to moralize and instead frame the issues as process gaps, you’ll instantly lower the temperature. You’ll also make it easier for everyone to engage honestly about what’s broken. This sounds obvious, but in practice, it’s where many leaders stumble. They want to show they’re decisive, so they come in with a list of culprits. But real progress starts when you decide you’re not there to prosecute. You’re there to build.
Quantify What’s Broken
Once you’ve created breathing room, you need to understand exactly what you’re dealing with. I’m amazed how many program managers inherit a mess but never truly quantify it. Instead, they keep things vague. They talk about “lack of alignment,” “quality concerns,” or “delivery risks.” These phrases are tidy and non-committal—and they’re also useless.
You can’t fix what you can’t describe. You have to be willing to state in plain language what is broken, why it matters, and what it’s costing. When you strip out the jargon and excuses, you often find the real risks are both simpler and scarier than you thought. Maybe documentation is nonexistent. Maybe no one knows how core modules actually work. Maybe the vendor has been quietly billing for “out-of-scope” work that was never agreed. Whatever it is, shine a light on it early.
One of the most important lessons I’ve learned is that executives do not respond to generic complaints. They respond to clear business impact. If you say, “Testing coverage is inadequate,” you’ll get polite nods. If you say, “A critical defect could halt operations for four weeks and cost us $500,000,” you’ll get immediate attention. The goal isn’t to catastrophize—it’s to describe reality in a way that drives action.
On Paper vs. In Reality
This is where most program managers get blindsided. On paper, the plan looks clean and predictable—three sprints, a roadmap, maybe a Gantt chart or two. But if you’ve ever actually tried to deliver anything complex, you know the reality is a lot messier. It’s a tangle of shifting priorities, fixed deadlines, endless meetings disguised as workshops, and a steady stream of well-meaning chaos.
If you’re wondering why it feels so hard to get traction, it’s because you’re not managing a process—you’re navigating this:
Stabilize Before You Build
After you’ve articulated what’s wrong, you have to decide how to approach the fix. This is where adrenaline takes over. Many managers try to tackle everything at once: rewriting requirements, renegotiating contracts, rebuilding trust, fixing code, launching new workstreams—all in parallel. The optics look impressive for about three weeks, until it collapses under its own weight.
If you’ve inherited a truly troubled program, you need to be methodical. Start by stabilizing. Freeze non-essential development. Contain the most urgent problems—the ones actively damaging credibility or delivery. Establish a steady cadence of communication so stakeholders see progress and feel someone is finally in control. Only after the immediate fires are contained should you move to remediation: cleaning up technical debt, clarifying scope, resetting expectations with vendors, and rebuilding trust in the team’s ability to deliver. And only when the basics are working should you accelerate and start adding new features or scaling up.
This sequence sounds almost too simple, but I’ve yet to see a rescue succeed without it.
Reset Relationships with Vendors
If you’re dealing with external vendors—and most large programs involve them—you’ll need to take an even more measured approach. Vendors have their own pressures and incentives. When a project gets rocky, it’s not unusual for them to default to protecting their revenue, their reputation, and their margins. You don’t need to be hostile, but you do need to be clear-eyed.
Before you engage, go through the contract line by line. Know exactly what was promised, what was delivered, and what is out of scope. Many program managers skip this step, relying on goodwill and vague assurances. That’s how you end up paying for work twice or accepting delays that were never yours to absorb.
When you meet with your vendor, set a tone that is professional but firm. Make it clear you want a predictable, productive relationship. Acknowledge the difficult start, but insist on transparency moving forward. While you’re doing this, quietly begin researching alternatives. Knowing you have options is the surest way to negotiate from a position of strength. It doesn’t mean you’ll switch providers, but it does mean you won’t be held hostage.
Show Progress Early
Rescues are stressful because everyone expects instant transformation. You can’t fix everything in a month, but you can create signals that progress is real. Early wins matter. Even something as modest as publishing an accurate schedule, resolving a critical defect, or producing a clear status update can restore confidence.
Stakeholders don’t need perfection. They need evidence the program is finally under control. When people see that you have a plan and can deliver on small promises, they’re far more likely to trust you with the bigger ones.
The Opportunity Hidden in the Mess
Inheriting a failing program can feel like a punishment. It can be exhausting and thankless. But it’s also one of the fastest ways to build credibility as a leader.
Anyone can manage a project when everything is going well. Few people can walk into chaos, lower the temperature, tell the truth, and create a path forward. If you can do that—without theatrics or blame—people will remember.
That’s the paradox of the hot potato. The same assignment that feels like a liability is often the best opportunity you’ll ever get to prove you can lead.
If you found this helpful, consider subscribing. Each week, I share lessons on program leadership, delivery discipline, and the unglamorous work of making complex things actually happen.