How to tell leadership a project is delayed

You know the date is unlikely to hold, but the team still has one more fix to try. Waiting feels responsible, since you might still recover. The problem is that leadership then hears about the delay after customers, sales, or another team has already planned around the old date.

This article covers when to escalate, how to check your facts, how to present the delay, and how to keep people updated until the work is back on track. Use the five-part message as soon as the change is big enough that someone else would decide differently.

The advice comes from Wes Kao, who teaches managing up and persuasive communication; Shreyas Doshi, former product leader at Stripe, Twitter, and Google; and Molly Graham, who led teams at Facebook, Quip, and the Chan Zuckerberg Initiative.

Speak up when the risk affects other people's plans

You don't need to wait until a delay is certain. Escalate when the odds or the impact have changed enough that leadership might adjust scope, staffing, what you tell customers, or another commitment.

Use probability language if the result is still uncertain: "The September 4 date is now at high risk. We'll know by Thursday whether the fix restores it." That's more useful than keeping the status green until the last attempt fails.

Don't let the first message be a surprise

On his podcast with Wes Kao, Lenny Rachitsky describes a weekly update he used to send with his priorities, the blockers he needed help with, and whatever else was on his mind. Kao agrees with the idea behind it: your manager shouldn't find out about a real problem at the last possible moment.

A regular written update gives leadership a record of the risk over time. When the status changes, you can point back to what you already told them instead of reconstructing weeks of warning signs in an emergency meeting.

Confirm five facts before the conversation

1. The old commitment: date, scope, customer, and owner.
2. The current state: what's done and what's blocked.
3. The cause: what's actually causing the delay, and the evidence for it.
4. The consequence: who or what is affected by each option.
5. The next decision: scope, date, staffing, or risk acceptance.

Keep the cause separate from blame. "Security review started two weeks late because the design changed after approval" tells people what happened. "Security always blocks us" hides the decision that actually went wrong.

Use status, cause, consequence, options, and recommendation

Put the status in your first sentence. Nobody should have to guess whether you're flagging a risk or telling them the date has actually moved.

Talk about what could go wrong before the project starts

Shreyas Doshi uses pre-mortems to give people permission to discuss what could go wrong. Teams often sit on their concerns because they don't want to sound negative. Putting the conversation on the calendar takes that pressure off.

Before a major commitment, ask everyone to imagine the launch failed and write down why. Give each likely reason an owner, an early warning sign to watch, and a point at which someone escalates. Then you're having the hard conversation months earlier, when it still costs you very little.

Escalate what you can't decide on your own

Molly Graham says to escalate when your team doesn't have the context or the authority to settle a decision. She points out that people often treat escalating as proof they failed, then waste a week arguing about something management could sort out in ten minutes.

When two teams disagree, go up together. Write down the facts you both agree on, each option, the tradeoff, and who owns the decision. Going up together shows leadership the choice that's actually stuck, instead of asking an executive to rule on which team behaved better.

Own what you could have done earlier

Leadership will want to know why the delay wasn't visible sooner. Answer directly:

Name the signal you missed and what you're changing. Don't spend so long apologizing that there's no time left to talk about the fix, and don't promise a complicated project will never slip again.

Tell each group what it means for them

• Executive sponsor: outcome, customer or financial consequence, options, recommendation.
• Sales or customer success: affected commitments, approved customer message, next update time.
• Engineering or delivery: changed scope, technical cause, owner, validation criteria.
• Customer: what changes for them, revised expectation, mitigation, and contact.

Keep the facts the same for everyone. Change the level of detail and the wording to match the decisions each group has to make.

Keep people updated until it's fixed

Say so clearly when the work is back on plan, or when the new date is the one everyone is working to. Write down what the team learned after you've shipped, once the emergency is over.

Frequently asked questions

Should I tell leadership before I have a new date?

Yes, once the existing date is seriously at risk. Share your current range, what will settle it, and when you'll have a firmer answer.

Should I tell my manager privately before a larger meeting?

Give the leader who owns it an early heads-up when you can, then make sure everyone who's deciding hears the same facts. Don't treat a private warning as a reason to leave the wider status green.

What if another team caused the delay?

Explain the dependency and what happened when. Your update still needs to cover the overall impact, the options, and the decision. Sort out who's accountable separately from deciding how to recover.

How do I answer, "Why didn't we know sooner?"

Name the earliest signal, how you read it at the time, and what will trigger an earlier warning next time. If you were missing information from another team, say how you'll change the way you check in with them.

The delay-conversation checklist