Short answer
Do not argue about the date - present the tradeoff. "We can hit the 14th with the payment flow and no admin tooling, or we can have all of it by the 28th" gives the decision back to the person who owns the deadline, in the currency they actually control: scope.
Engineers push back on deadlines badly for an understandable reason: the objection is technical, so it gets expressed technically. "That's not realistic, the migration alone will take three weeks" is accurate and lands as obstruction, because it answers a question about business commitment with a statement about engineering difficulty.
Whose Decision Is It
The date usually belongs to someone else - a customer commitment, a launch, a contract. When you say "no", you are taking a decision that is not yours. When you say "here is what fits", you hand back a decision they are entitled to make and better positioned to make, because they know things about the commitment that you do not.
The three-option frame
Almost every deadline conversation resolves if you arrive with three concrete options rather than one objection:
- Full scope, later date. "Everything we discussed, delivered the 28th."
- Reduced scope, their date. "The 14th, with the payment flow working end to end but admin tooling done manually for the first month."
- Their date and scope, explicit cost. "The 14th with everything, if we defer the test coverage and accept we'll spend the following sprint on the fallout. I don't recommend it, but it's a real option."
Including the third option matters. It proves you are not hiding behind engineering caution, and it makes the cost of the decision explicit rather than something you absorb silently and resent later.
The script
Say this
"I want to make the 14th work, so let me show you what fits. If we build the payment flow properly and handle refunds manually for the first month, the 14th is realistic. If we need the admin tooling too, it's the 28th. Which of those is closer to what you need?"
You have opened cooperatively, been specific about what is achievable, and closed with a question. Nobody has been told no.
Put the estimate in writing, once
Follow up in one short message: what was agreed, what is in scope, what was explicitly cut. Not as a defensive manoeuvre but because deadline conversations are remembered selectively by everyone involved. One paragraph in a channel, at the time, prevents the version of this conversation that happens in six weeks where nobody agrees what was decided.
When they say the date is non-negotiable anyway
Sometimes the date really is fixed - a regulatory deadline, a contract, a conference. Then the conversation stops being about the date and becomes about what you cut, and that conversation must still happen explicitly.
- Name what will not be done. "Then we ship without the audit log and add it in the following sprint" - agreed, not assumed.
- Name the risk you are accepting. "We'll be light on test coverage in the refund path, so expect some manual support load."
- Do not silently absorb it with overtime. A team that hits impossible dates by working weekends teaches the organisation that its dates were possible.
That last one is the most expensive mistake in this whole conversation. Heroics get rewarded once and then become the baseline expectation.
Frequently asked questions
How do you tell your manager a deadline is unrealistic?
Do not lead with the deadline being unrealistic - lead with what is achievable. Present two or three scope-and-date combinations and ask which is closest to what they need, which hands the decision back to whoever owns the commitment.
What if my manager insists on the deadline anyway?
Then the conversation shifts to what gets cut, and that must be explicit. Agree what will not be delivered, name the risk being accepted, and confirm it in writing. What you must not do is absorb it with unpaid overtime, because that teaches the organisation the date was achievable.
Should I pad my estimates?
Include the work people forget rather than adding a secret multiplier. Code review, testing, deployment, migration and the inevitable interruptions are real work, and estimating them explicitly is more defensible than a padded number you cannot justify.
How do I push back without sounding negative?
Open with the intent to make it work and close with a question. "I want to hit the 14th - here's what fits, which of these is closest to what you need?" is collaborative. "That's not realistic" is a verdict, and verdicts invite argument.