Explain the constraint, then offer realistic alternatives. A deadline is fixed by four things: scope, time, people and quality, so when someone asks for more in the same time, the most useful answer is usually "here is what has to give. Which one?" And when a request can't be delivered safely or realistically whichever way you turn those controls, a clear no, with the reason, is the right answer.

Our humor book HR-Approved Ways to Say What Programmers Are Really Thinking has a section on deadlines and estimates, and several of its "HR-approved" lines turn out to be genuinely good scripts. This guide collects the serious versions, with the reasoning behind them.

Explain the constraint, then show the options

A bare "no", or "that's impossible", leaves the person asking with the same deadline and no information to act on. Explaining what actually limits the work, and then showing the options, puts you on the same side of the table: you both want the thing shipped, and you are showing them the controls.

The four controls, and what to say about each:

  • Scope. "If the date is fixed, which of these features can ship in the next release instead?" Usually the most effective lever, because most plans include work that can wait.
  • Time. "If all of it has to ship, the realistic date is the 24th, not the 10th."
  • People. Be careful here. Adding people late often slows a project down, because newcomers need onboarding from the people already doing the work. Fred Brooks put it as Brooks's Law in 1975; we explain it in programmer inside jokes, explained.
  • Quality. "We can hit the date if we skip the load testing. Here is the risk that leaves." Sometimes a business will knowingly take a risk like that. It should be their decision, made in writing, not yours made quietly. Some risks are not a fair trade at all, which is the next section.

When a clear no is the right answer

Offering options assumes at least one of them is safe and realistic. Sometimes none is, and then a clear refusal is the professional answer, not the difficult one. Typical cases:

  • Meeting the date means shipping something unsafe. A data migration with no tested rollback, a payment change with the testing removed, a known security hole left open.
  • No amount of scope cutting gets there. The work depends on something that won't exist in time: another team's API, a vendor's approval, hardware that hasn't arrived.
  • Saying yes would mean hiding the risk. If the only way to agree is to stay quiet about what will probably break, agreeing is the bigger problem.

Say it plainly, give the constraint, and offer what you can do instead: "I can't commit to the 10th for the migration. Without a tested rollback, a failure there could lose customer data. With a rollback in place, I can do it by the 17th, or we can ship the read-only part on the 10th." That is still a no, but it gives everyone something real to decide with.

Separate the estimate from the deadline

An estimate is a guess with uncertainty. A deadline is a commitment. Trouble starts when an early guess ("roughly two weeks, maybe?") gets copied into a roadmap as a date. Two habits help:

  • Give ranges, not points. "Two to four weeks, depending on how the payment provider's API behaves" is more honest than "three weeks", and it tells people where the risk is.
  • Say how confident you are, and what would make you more confident. "Early estimates carry significant uncertainty. After a two-day spike I can give you a much tighter number."

Scripts for the common situations

"Can you just squeeze it in?"

The book's HR-approved line is the script: "I can take this on if we deprioritize something else. Which item should move?" It says yes, it is polite, and it hands the prioritisation back to the person who owns priorities. If nobody is willing to move anything, that tells you something useful about how urgent the request really is.

When the estimate came from people who won't do the work

"I'd like the implementing team to have input on the timeline. Can we take a day to size it before we commit to the date?" Ask for the input before arguing with the number. A number the team produced is one the team can defend.

When nobody understands the work well enough to estimate it

"We may need a short spike before committing to an estimate." A spike is a time-boxed piece of investigation, a day or two, whose only output is knowledge: what the hard part is and roughly how big it is. It costs a little time and saves the much larger cost of committing to a number nobody believed.

When "almost done" isn't

Say what's left, not a percentage. "The main flow works. Error handling, the edge cases QA found, and the migration are left, about four days." Percentages hide the fact that the last stretch, the part users actually touch, is often the slowest.

When the date really is immovable

Sometimes it is: a conference, a regulation, a contract. Then the conversation is mostly about scope, and if no cut makes the date safe, it is one of the cases for a clear no above. "Given the date can't move, here is what we can ship by then, and here is what follows two weeks later." Put that in writing so that nobody is surprised on the day.

After the crunch

If the team made an impossible date by working every weekend, say so in the retrospective, calmly: "We hit it by working weekends. A sustainable pace for the next release may be worth discussing." The risk otherwise is that the heroic effort quietly becomes the new baseline. In the book's developer translation of that moment, leadership's takeaway is that the deadline wasn't aggressive enough.

The short version

Explain the constraint, show the four controls with realistic options, and let the person who owns the priorities choose. When none of the options is safe or realistic, say no clearly, and say why.

And for the version of this conversation you have in your head first, the deadlines section of our book has it word for word. If the conflict is about a pull request rather than a date, see how to write code review comments that don't start a fight.