Prabhubalaji
Ragavan

Step 1: Don't Manage the Delay - Diagnose It First

The instinct when something breaks is to immediately start solving. Resist it. The first 30–60 minutes after a delay surfaces should be pure diagnosis. You need to answer three questions before anything else:

When I was at Amazon working on Fire TV, a crash spike surfaced two weeks before a major firmware release. The first instinct was to slip the date by a month. When I dug into the actual data - device logs, crash distribution by firmware version, affected SKUs - the real issue was scoped to one specific hardware configuration. We isolated it in 48 hours. Slipping would have been the wrong call. Diagnosis before decision. Always.

Step 2: Create a Single Source of Truth - Immediately

The moment a delay is confirmed, information fragments across Slack threads, email chains, and hallway conversations. Your job is to stop that fragmentation before it starts. Within the first hour, I create or designate a single incident channel or document: current status, owner, what's been tried, next checkpoint. This isn't bureaucracy - it's how you prevent ten people from working on the same thing in parallel, and how you maintain trust with stakeholders when things get messy. Transparency in a crisis builds more credibility than a perfect launch.

Step 3: Activate the Right Decision Framework - Not the Loudest Voices

High-stakes delays attract opinions. Your job as TPM is to create a structured decision space, not a free-for-all. For any significant launch delay, there are exactly three options:

At eBay, a late-cycle data quality issue affected an AI feature's accuracy on a subset of transaction types. Rather than holding the full launch or scrapping it, we scoped to segments where accuracy was validated and rolled out the remainder six weeks later. Response rate improvement still hit 42.4%. Partial launches are underused. They're often the smartest call.

Step 4: Protect the Team While Pushing for Resolution

Launch crunches are where team culture gets tested. When a delay hits, the pressure flows downhill fast - engineers get pinged constantly, context-switching kills resolution speed. My role in a crunch is to run interference: centralize status updates so engineers aren't fielding the same question from five stakeholders, set a cadence with updates at defined intervals rather than on demand, and keep escalation proportional. The fastest path to resolution is a focused team. Anything that fragments their attention slows you down.

Step 5: Run the Post-Mortem - Even When You'd Rather Move On

Once the launch lands, there's a temptation to close the chapter. Resist that too. Every significant delay is a system signal. The questions I always bring into a post-mortem:

The Underlying Truth

Delays are not failures of execution. They're failures of early detection - and early detection is a system problem, not a people problem. The programs I'm proudest of aren't the ones that launched perfectly. They're the ones where something went wrong, the team stayed aligned, we made a smart call under pressure, and we shipped something we could stand behind. That's the job. Not smooth launches - smart recoveries.