Every engineer eventually sits across from a stakeholder who says "we need this in three weeks" about something that genuinely needs six. The instinct is either to say yes and quietly hope for the best, or to say "that's not realistic" and watch the conversation get defensive fast. Neither approach actually works well, and the difference between engineers who get their pushback taken seriously and engineers who get overridden usually isn't technical skill — it's how the pushback is framed.
Why "That's Not Realistic" Fails on Its Own
Stated flatly, "that's not realistic" sounds like a subjective opinion competing against the business's subjective sense of urgency. From the stakeholder's side, it can read as "I'd prefer not to" dressed up in technical language, especially if there's no visible reasoning behind it. Even when the estimate is genuinely well-founded, an unexplained rejection invites the listener to discount it as caution rather than analysis.
The fix isn't softer language — it's showing the work behind the number, the same way you'd want a vendor to show their work if they quoted you a price that seemed off.
Replace the Verdict With the Breakdown
Instead of leading with a conclusion, lead with the components that add up to it:
"Here's what three weeks would need to cover: two days for the database migration, four days for the API layer, three days for the frontend integration, two days of testing, and a buffer for the third-party payment integration, which historically takes longer than expected because of their sandbox approval process. That's closer to five to six weeks with reasonable buffer, not three."
This does two things a flat rejection doesn't. It gives the stakeholder something concrete to evaluate rather than just push back against, and it invites them into the trade-off conversation instead of putting them in an adversarial position against your estimate.
Offer Options, Not Just an Objection
A pushback that ends at "it can't be done in three weeks" leaves the stakeholder with nothing to do except argue. A pushback that continues into "here's what we can do in three weeks" gives them a decision to make instead of a wall to push against:
- Full scope, longer timeline — the six-week version with everything included.
- Reduced scope, original timeline — ship the core flow in three weeks, defer the payment integration's edge-case handling to a fast-follow.
- Same scope, more resources — bring in additional help to parallelize what can actually be parallelized (which is often less than people assume).
Stakeholders are usually optimizing for a business outcome, not specifically for an unrealistic date. Giving them real trade-offs to choose from usually resolves the tension faster than defending a single number.
Separate the Estimate From the Person Giving It
A useful reframe in these conversations: the estimate isn't a statement about how hard you're willing to work, it's a description of how the actual pieces of the system fit together and how long each piece has taken historically. Framing it that way — "here's what similar work has taken before" rather than "here's what I personally feel comfortable committing to" — shifts the conversation from a negotiation over your effort to a shared look at the underlying reality.
Watch for the Deadline That's Actually a Symptom
Sometimes an aggressive deadline is arbitrary. Sometimes it's tied to something real — a contractual commitment, a conference, a competitor's launch — that wasn't communicated when the ask was made. Asking directly, "what's driving the three-week timeline specifically?" often surfaces information that changes the conversation entirely. If the real constraint is "we need a demo-able version for a specific meeting," that's a very different, often easier, problem than "we need the fully shipped feature."
When the Answer Is Genuinely No
Sometimes, after all the trade-offs are laid out honestly, the answer really is that the full scope can't happen in the requested time without cutting a corner nobody should accept — skipping security review, skipping load testing on a payment path, shipping something that will break under real usage. In that case, the goal isn't to win the negotiation. It's to make sure the decision-maker is choosing the risk with full information, rather than discovering it after the fact. A clear, written record of the trade-off — "we're shipping without X testing to hit this date, which carries Y risk" — protects both the project and the person who raised the concern.
The Takeaway
Pushing back on a deadline well isn't about being more assertive or more diplomatic — it's about replacing a verdict with a breakdown stakeholders can actually evaluate, and replacing an objection with options they can actually choose between. Engineers who do this consistently tend to get their concerns taken seriously far more often than engineers relying purely on confidence or seniority to make the case. It's the same instinct behind a team that estimates timelines honestly rather than overpromising in the first place — treating the estimate as a shared problem to solve together, not a battle to win.
Anchor text used above: "a team that estimates timelines honestly rather than overpromising" → links to https://www.zoraz.net/
