Work through the words
How to Push Back on an Unrealistic Deadline
You don't need to choose between silently accepting an impossible commitment and sending an angry email. The useful middle is being clear about the constraint, the consequence, and what needs to change.
From Mara at Muze
The short answer
The best way to push back on an unrealistic deadline is to make the constraint and tradeoff explicit rather than simply saying the deadline is impossible. State what cannot realistically be delivered, explain the concrete reason, and propose a decision: change the date, reduce the scope, add resources, or explicitly accept the risk. Keep frustration separate from the immediate decision unless the larger process problem also needs to be addressed now.
Start with the outcome, not the frustration
Before drafting, decide what you need the other person to do. You may want the deadline changed, the scope reduced, resources added, the work sequenced differently, or the risk explicitly accepted. You may also want to prevent the same process problem later, but that does not always belong in the first message.
A difficult message gets much easier to write once you know what you want the recipient to do.
- Change the deadline
- Reduce the scope
- Add resources or decision-makers
- Change the sequence of the work
- Explicitly accept a known risk
- Address the planning process in a separate conversation
I'm really frustrated that this timeline was committed without consulting the team.
With the current scope, I don't think the team can reliably deliver by August 28. Can we review either the scope or the date before we finalize the commitment?
The first sentence expresses a valid feeling but does not establish a decision. The second identifies the constraint, the risk, and the action needed.
Separate the immediate problem from the larger problem
The immediate problem may be that the deadline cannot be met. The larger problem may be that commitments are being made without the responsible team. Both matter, but combining them can make the recipient defend the decision-making process instead of addressing the delivery risk.
If your first paragraph is about not being consulted, your manager may spend the conversation defending how the decision was made. If the immediate objective is changing the delivery plan, lead there.
You can preserve the process concern without making it compete with the urgent decision: first confirm the date, scope, and risk; then ask for a separate review of how commitments are made. If the same pattern is creating ongoing harm, document that pattern after the immediate delivery choice is clear.
Use observable constraints instead of motives
Describe the work, dependencies, capacity, and review steps that make the date difficult. Avoid claiming to know why someone made the commitment unless you have direct evidence. Facts create a decision; judgments about motives create an argument.
Leadership keeps making impossible promises because they don't understand engineering.
The plan requires implementation, security review, and partner validation inside eight working days. Security review alone normally requires four, so the current scope and date do not fit without a change.
The better version gives the recipient something concrete to evaluate. It also leaves room for a solution instead of assigning intent and inviting a defense.
Use the evidence you actually have. If the review duration is an estimate, say that it is an estimate. If a dependency is not confirmed, call it a dependency to confirm rather than a settled fact. Precision makes pushback more credible.
Make the tradeoff visible
An unrealistic deadline is usually a tradeoff problem disguised as a date problem. Put the available choices next to the consequence so the recipient can make a decision.
We can keep the August 28 date if we remove X and Y from the first release. If the full scope is required, September 11 is the earliest date I believe we can commit to responsibly.
This changes the conversation from ‘I don't like the deadline’ to ‘Here are the decisions available.’ A useful pushback message does not need to solve every planning question; it needs to make the cost of each option visible.
- What can be delivered by the requested date?
- What must move or be removed?
- What additional resource would actually change the timeline?
- What risk is being accepted if the date stays fixed?
Don't bury the request
Your recipient should be able to tell what decision or action you need from them without decoding the message. Context is useful when it supports the decision; history that does not change the decision can wait.
I wanted to follow up on the timeline and provide some context. We talked about this briefly last month, and there have been several changes since then. I know the launch is important and everyone has been working hard. I also want to make sure we are aligned, because there are a few concerns from the team and some dependencies that may be difficult. Given all of that, I was wondering whether it might be possible to revisit the date.
The current scope cannot be delivered reliably by August 28. Please choose one of these options by Thursday: keep the date and remove X and Y, or keep the scope and move the date to September 11. The open security review is the constraint driving the recommendation.
The better version puts the decision first, gives two workable options, and includes only the evidence needed to understand the recommendation. It is direct without being hostile.
- What am I asking for?
- Can the recipient identify it in one read?
- Did I provide enough evidence to understand why?
- Did I add history that does not change the decision?
Bring Mara the situation, the message you received, or your rough draft. She'll help you identify the real request, pressure-test how it may land, and shape the message with you.
Work through it with Mara →How direct should you be?
Directness depends on your confidence in the constraint, the urgency, the relationship, whether this is a repeated issue, who has decision authority, and whether documentation matters. Softer language is not always kinder, and forceful language is not always clearer.
I want to flag a delivery risk before we finalize the date. Can we review the scope and dependencies together?
We cannot responsibly commit to the current date with the agreed scope. We need to change either the date or the scope.
I raised this delivery risk on August 6, and the underlying constraints remain unresolved. Before the date is communicated externally, I need us to confirm which tradeoff we're accepting.
Use the collaborative version when a joint review could genuinely resolve uncertainty. Use the direct version when the constraint is established and a decision is overdue. Use the escalation version when the risk has already been raised, the pattern matters, or you need a clear record before the commitment travels further.
A worked example: push back without a public confrontation
Situation
A manager committed an engineering team to a two-week delivery. The team estimates four weeks. The employee wants the deadline reconsidered, does not want to confront the manager publicly, and wants to address the planning process later.
Rough draft
I wanted to raise something about the deadline because I have been thinking about it since the planning meeting. I was surprised that the two-week date was shared since the team was not consulted, and this is similar to what happened with the reporting project last quarter. We have been trying to explain that the work is more involved than it looks, and I know everyone wants to move quickly, but there are implementation details, testing, and the partner review. I don't want us to miss the date or make the team look unreliable. Could we maybe revisit the timeline and talk about whether it is realistic?
Mara's critique
- The request is buried at the end, so the manager has to read through history before finding the decision needed.
- The opening invites a blame debate about who was consulted rather than focusing on the delivery risk.
- The immediate timeline problem and the larger process problem are competing for attention.
Revision
I want to flag a delivery risk before the two-week date is confirmed. With the current scope, the team estimates four weeks because implementation, testing, and partner review are all still required. We can either move the date to the four-week estimate or keep the two-week target by reducing the first release to the highest-priority work. Which tradeoff should we take? I would also like to schedule a separate conversation about involving the team before future commitments are made.
Why it works
The revision leads with the delivery risk, names the evidence without overstating it, and asks for a concrete choice. It preserves the concern about consultation but gives that process issue its own place, so the manager can decide about the immediate plan without first defending the past.
Should this be an email at all?
A conversation may be better when the disagreement needs back-and-forth, nuance matters, the relationship needs care, or emotion is high enough that a written message could harden positions. Ask for a short conversation when the decision is easier to make together.
I think we have a real mismatch between scope and timeline. Can we spend 15 minutes reviewing the tradeoffs before the date is finalized?
Written communication is useful when specific facts matter, asynchronous coordination is necessary, a decision needs confirmation, documentation is useful, or you need a concise follow-up after a conversation. After talking, confirm the decision in writing: state the chosen scope and date, the accepted risk, and the owner for the next step.
Questions that come up
What if my manager already promised the deadline externally?
Describe the gap without treating the external promise as proof that the team must absorb the full risk. Offer a minimum viable scope, a revised date, or a clearly named risk for the manager to accept. If the commitment cannot change, ask what work will be deprioritized and who will communicate the resulting limitation.
Should I say the deadline is ‘impossible’?
Usually, explain why the deadline is not a responsible commitment instead of relying on the word ‘impossible.’ If a hard dependency truly makes delivery impossible, name that dependency. Otherwise, describe the confidence level and the tradeoff: ‘We could attempt it, but we cannot commit to the full scope reliably without changing the date or adding capacity.’
How much evidence should I include?
Include enough to make the constraint understandable and the recommendation credible: the remaining work, material dependencies, capacity, and any review or approval step that controls the date. Leave out detail that does not affect the decision, and label estimates as estimates.
What if this keeps happening?
Address the immediate commitment first, then document the repeated pattern with dates, risks raised, and outcomes rather than conclusions about motives. Ask for a process change, such as a planning review before external dates are shared. If the pattern creates serious harm and ordinary escalation does not help, use the appropriate manager, people partner, or formal channel.
Your situation will be more specific than any template
The right message depends on the actual constraint, who made the commitment, what decision you need, and how much of the larger issue belongs in this conversation. Mara can help you work through those tradeoffs before you send anything.
Talk it through with Mara →
