An executive wants a firm date for work your team has not scoped yet. What do you do?

Two ways to lose the room

There are two failure modes here and interviewers listen for both. The first is capitulation: you feel the pressure, pick something that sounds brave, and say "end of Q3." You have converted the executive's uncertainty into your own liability, and when the date moves you become the person who missed a commitment rather than the person who flagged a risk. The second is stonewalling: "I can't give you a date until we've scoped it." That is technically true and organisationally useless, because the executive is not asking out of curiosity. They have a commitment of their own to make and you have just refused to help them make it.

The strong answer refuses the premise that those are the options. You can always say something useful about timing today; what you cannot do is say it with more precision than you have earned. The whole skill is being precise about your imprecision.

Ask what the date is for

Before you estimate anything, find out what decision the date is feeding. Most candidates skip this entirely because the question sounds like it is about estimation, and it is the single move that separates a senior answer from a competent one.

The answers demand very different things of you. A customer contract with a delivery clause needs a date you can defend, which means being conservative and explicit about scope. A booked marketing launch needs a date that will not move, and the executive would probably rather have less product on a fixed day. A board slide about direction may be satisfied by "second half, first customer-visible piece in September." And if they are choosing between this initiative and another, they do not need a date at all — they need a relative cost, which you can give far sooner and far more reliably.

Asking this also changes the register. You stop being someone dodging a question and start being someone solving their problem, which is the only durable way to buy patience while you go and find out.

Separate what is known from what is not

Then say out loud which parts of the work you understand and which you do not. Never present one number that quietly averages confident work with guesswork: the executive cannot see the seam and will treat all of it as equally solid.

For a payments-provider migration the split might be: the API integration and the reconciliation job are work this team has done twice before, roughly two weeks each; the data backfill is understood in shape but nobody has measured the volume, so it is two days to three weeks; and whether the provider's sandbox supports the refund flows finance depends on is genuinely unknown, with the fallback being a rewrite nobody has costed.

That structure does something a single number cannot: it shows the executive where the risk lives, which means they can help. They can often remove an unknown you cannot — get an answer out of the vendor in a day, or tell you refunds are not needed in phase one, which deletes your largest unknown outright.

A range carries its confidence and its assumptions

Give a range, and attach two things to it: how confident you are, and what it assumes. A range without assumptions is just a wider guess, and it will be quietly collapsed to its optimistic end the moment you leave the room.

Case	What it assumes	Estimate
Good	Sandbox supports refunds, backfill is under 50 GB, team stays whole	6 weeks
Likely	Refund flows need one adapter, backfill needs a batched job	9 weeks
Bad	Refund flows unsupported, component needs rewriting	14+ weeks

Keep the arithmetic visible: four weeks of familiar work, plus one to three weeks of backfill depending on volume, plus a week of integration buffer, gets you six to nine; the bad case adds a rewrite whose size is itself unknown, which is why it carries a plus sign rather than a number. Say the confidence in plain words — "I'd hold nine weeks at about seven in ten, and I would not sign a contract on six" — because a percentage without a sentence around it sounds like theatre.

Buy the information with a spike

You identify unknowns specifically so you can close them cheaply. Propose a timeboxed investigation: two engineers, five working days, three questions — does the sandbox support partial refunds, how large is the historical table, can the backfill run without a write freeze. On the sixth day you return with either a date you will commit to or a materially narrower range.

Timeboxed means it ends whether or not it succeeds. An open-ended discovery phase is how a scoping problem becomes a schedule problem, and if the spike ends without answers, that is itself the answer: the risk is real and the pessimistic case has become more likely. Either way you are no longer refusing to commit — you are telling the executive that the cost of a firm answer is one week, and naming the day they get it.

Fix scope or fix the date, not both

Where the pressure is real, offer the trade explicitly. If the date is immovable because of a contract or a conference, scope becomes the variable and you name what you will guarantee on that date and what you will not: integration and reconciliation ship, the backfill runs behind a flag on historical data only, refunds follow later. If scope is genuinely fixed, the date is the variable and no amount of pressure changes that. Adding people to a late, poorly understood project usually makes it later, and saying so calmly beats absorbing the pressure and hoping.

The version to have ready sounds like this:

"I can't give you a date I'd stand behind today, but I can give you one on Friday next week. Here is what I know now: the integration work is four weeks and I'm confident in that. The open question is whether the provider supports our refund flows, and if it doesn't, that adds anywhere from two weeks to two months. So my honest range is six to fourteen weeks, and I'd hold nine. Give me two engineers for a week to close that question and I'll come back with a date I'll commit to. If the September launch is fixed regardless, tell me now and we'll talk about which parts ship in September rather than which week we finish."

Communicating a slip, and the cost of holding it

The moment you have evidence the date is at risk — not proof, evidence — you raise it, in the same conversation where you propose what you intend to do about it. Two weeks into a nine-week estimate the signal is usually a leading one: a dependency team has not started, a spike came back worse than expected, someone is out. That is the point at which the executive still has options — descope, move the launch, buy help, re-sequence something else. Four weeks later they have none of those and the same problem.

Say the impact in their units, not yours. "We are behind" is a feeling. "Refunds will not be in the September release; the integration still lands on the 12th; the October customer commitment is unaffected" is a decision brief. Bring a recommendation with it and be clear about what you need from them.

What breaks when you sit on it is not the schedule, it is your future estimates. An executive who learns late twice stops treating your dates as information and starts adding a private buffer to everything you say, or goes around you to your engineers for a second opinion. Report a slip early with a plan and you get trusted with the next ambiguous thing. Report it at the deadline and next time the date is simply handed to you, which is precisely the situation this question is about.

The deliverable is never the number. It is a decision the executive can make today, plus a specific date on which the number gets better — and that only holds if you have shown them where your uncertainty actually lives.