The director who wants a date you cannot commit to

"Your director wants a date you can't commit to. Respond."

What the question is actually testing

Not whether you will push back. Three things:

Whether you treat a date as a negotiation about scope and confidence, rather than a yes or no. "No" and "yes" are both bad answers; the good answer changes the shape of the question.
Whether you can quantify uncertainty. "It might take longer" is a feeling. "Historically work like this has taken 6 to 11 weeks, so I'd give you 60 percent confidence on the 15th and 90 percent on the 29th" is an engineering statement.
Whether you understand what the director is actually solving for. A date is almost never the goal; it is a proxy for a customer commitment, a board meeting, a contract, or a dependency. Find the real constraint and you often find a better answer than the one being demanded.

Structure: first move, information I would gather, line I would not cross.

The answer

First move: find out what the date is for

Do not answer the date question until you know what it is serving. The question is not confrontational if you ask it with genuine curiosity:

"Before I answer, help me understand what the 15th is anchored to. Is that a customer commitment, a contract date, a conference, or is it a stretch target? It changes what I'd propose."

The answers lead to completely different responses:

What the date is	Implication
Contractual or regulatory	Genuinely immovable. The variable is scope, and I need to find the smallest thing that satisfies it
A customer commitment already made	Movable at a cost that is not mine to price. I supply the options; the director decides what to tell the customer
An external event (conference, launch)	Usually immovable in date, very movable in what "shipped" means
A dependency (another team needs it)	Often negotiable once both sides see the whole chain
An aspiration or an anchor	Fully negotiable, and often the director is testing whether I will simply agree

That last row matters more than people expect. A director who states a date and gets immediate agreement learns nothing about the team's capacity, and a lead who agrees to dates they cannot hit becomes someone whose estimates are worthless within two quarters.

Then: supply options with costs, never a refusal

The move that changes the conversation is replacing a yes-or-no with a menu.

"I can't commit to the full scope on the 15th, and I don't want to give you a date I don't believe, because then you'd plan on it. Here are three things I can commit to.

One: the full scope, and my honest forecast is 60 percent confidence on the 29th, 90 percent on the 12th of next month.

Two: the 15th, with the bulk import and the admin UI cut. That's the core flow working end to end for a single user. I'd want to check with you whether that's enough for what the date is serving.

Three: the 15th with full scope, if I get two engineers from platform for three weeks. I'd put that at 70 percent, because onboarding cost eats some of the gain, and I'd want to be honest that it slows platform's roadmap.

My recommendation is two, because the pieces I'd cut are the ones our first customers use least, and we can ship them a fortnight later without anyone noticing."

Four properties of that answer, and each is being scored:

It never says no. It says "here is what is achievable, at what cost".
It quantifies confidence rather than asserting a single date.
It names what gets cut, specifically, so the director can evaluate.
It ends with a recommendation. Presenting three options with no recommendation pushes the decision back to someone with less information, which is an abdication rather than a consultation.

The forecasting that makes it credible

The reason the confidence numbers are not made up:

Historical cycle time for work of this shape (last 18 comparable items):
  p50   6.5 weeks
  p75   8   weeks
  p90  11   weeks

We are 1 week in. Remaining scope is comparable to those 18 items.
  60% confidence -> ~the 29th
  90% confidence -> ~the 12th

Capacity check:
  6 engineers x 25 working days = 150 person-days
  minus on-call (15), interviews (8), support rotation (12), meetings (20)
  = 95 effective person-days, and I commit to 65-70% of that = ~65

Two habits here are what make a lead sound senior. Forecast with percentiles from historical cycle time rather than with story points, because points measure imagined effort and cycle time measures reality. And commit to 60 to 70 percent of theoretical capacity, because teams that commit to 100 percent miss every single time, and the gap is on-call, interviews, support and meetings that were always going to happen.

If the director pushes anyway

"I hear you, and I want to be clear about what I'm agreeing to. If we commit to the 15th with full scope, my honest estimate is that we hit it about one time in four. If we're going to take that bet, I'd want to plan for the other three outcomes now rather than in week three: what we tell the customer if we slip, and which pieces we drop first. I'd rather agree that today than improvise it under pressure."

That is the disagree-and-commit move done properly. You have not refused; you have made the risk explicit, put it on the record, and pre-agreed the contingency. If it slips, nobody is surprised and there is already a plan.

And then, importantly, commit genuinely. Dissent recorded, decision made, full effort behind it. A lead who visibly executes half-heartedly on a decision they lost is worse than one who never objected.

Then: write it down

Same day, short, to the director and anyone downstream:

"Confirming: we're targeting the 15th with the bulk import and admin UI out of scope, shipping those by the 29th. My confidence on the 15th for the reduced scope is about 85 percent. Risks: the payments integration is the long pole and depends on their sandbox being available by the 8th. I'll flag by the 8th if that slips."

Verbal commitments become different memories within two weeks. The written version is also what makes a later slip a known risk materialising rather than a surprise.

Where this goes wrong

Saying no. "We can't do that" is accurate and useless. It gives the director nothing to work with and positions engineering as an obstacle rather than a partner.

Saying yes and hoping. The worst option, and the most common. It buys three weeks of calm and spends all your credibility, because a lead whose dates are unreliable stops being consulted about dates at all.

Padding silently. Quoting the 90th percentile as if it were the estimate. Directors work out that your dates are padded and start discounting them, so you pad more, and now nobody knows anything.

Options without a recommendation. Handing over three choices and no opinion looks like collaboration and is abdication. You have the most information; use it.

Making it about the team's feelings. "The team will burn out" may be true and it is the weakest available argument, because it is unfalsifiable and it sounds like special pleading. "We hit this date one time in four" is the same concern expressed as a fact.

Not asking what the date is for. The single most common miss, and the one that most often unlocks a better answer than either party started with.

Interviewer follow-ups

"The director says the date is non-negotiable and so is the scope." Then I say plainly what that means and what I need. "Then we're committing to something I estimate at 25 percent. I'll run it that way, and here's what I need: a decision now on what we drop if we're behind at the halfway point, and the two platform engineers, because that's the only lever left. If neither is available, I want it on record that we're taking a bet, and I'd like us to agree today what we tell the customer if it doesn't land." Then I execute properly, because a recorded objection followed by half-hearted delivery is the worst of both.

"How do you know your estimate is right?" I do not, which is why I give a distribution rather than a date. The distribution comes from the last 18 comparable items' actual cycle time, so it already includes the interruptions, the unknowns and the estimation optimism that individual estimates always omit. It will still be wrong sometimes, which is what the 60 and 90 percent numbers are honestly saying, and I would rather be transparently uncertain than confidently wrong.

"Your team says the reduced scope is still not achievable." Then I have a problem I created by committing without checking, and I fix it immediately rather than defending the commitment. I go back with the same structure one level down: what is the largest thing we can commit to, what confidence, what would change it. Then I go back to the director the same day, because a correction on day three costs a conversation and a correction on day twenty costs the relationship.

"What if you're wrong and the team could have hit it?" Then I have been too conservative, and that is a real cost: it makes the team look slower than it is and it costs the business optionality. The fix is to track forecast accuracy over time, so I find out whether I am systematically pessimistic. If my 60 percent forecasts hit 90 percent of the time, my model is wrong and I should say so and recalibrate rather than enjoying the easy wins.

"How do you avoid being in this position?" Forecast continuously rather than at commitment time. If the director sees a burn-up chart with a confidence band every week, the date conversation happens early and gradually rather than as a single confrontation. Also: never let a date be set without engineering in the room, and if that is happening, that is the actual problem and it is worth raising directly with the director as a process issue rather than fighting it one date at a time.

Production evidence

Troy Magennis's and Daniel Vacanti's work on probabilistic forecasting is the basis for forecasting from historical cycle-time distributions rather than from estimates, and for expressing commitments as confidence levels. Vacanti's Actionable Agile Metrics for Predictability is the practical reference.

Amazon's "disagree and commit" leadership principle is the canonical framing for the escalation path: dissent is expressed clearly and recorded, the decision is made, and commitment afterwards is genuine rather than performative.

The DORA research on batch size and lead time supports the scope-reduction option structurally: smaller scope ships sooner and more predictably, so cutting scope is not merely a concession, it improves the forecast.

Will Larson's An Elegant Puzzle covers the capacity-commitment arithmetic and the practice of publishing a percentage of theoretical capacity, which is what makes the 60 to 70 percent figure defensible rather than arbitrary.

Interview delivery note

Open with the structure, then with the question nobody asks: "First move, information I'd gather, line I wouldn't cross. And my first move isn't to answer the date question, it's to ask what the date is anchored to. A contractual deadline and a stretch target need completely different responses, and quite often the real constraint has a better answer than either of us started with."

Then the menu: "Then I'd give options with costs rather than a yes or no. Full scope at 60 percent confidence on the 29th and 90 percent on the 12th. Or the 15th with the bulk import and admin UI cut. Or the 15th with two borrowed engineers, at 70 percent. And I'd recommend one, because handing over three options with no opinion is abdication, not collaboration."

The depth signal is where the numbers come from: "the confidence levels come from the actual cycle time of the last eighteen comparable items, not from story points, because points measure imagined effort and cycle time measures what happened. And I'd commit to about 65 percent of theoretical capacity, because the rest is on-call, interviews and support that were always going to happen."

Close with the line: "The line I wouldn't cross is giving a date I don't believe. Not because it's dishonest, though it is, but because they'd plan on it, and the cost lands on people downstream who had no way to know."

The Staff & Team Lead Interview Reference