A software estimate is often treated, on both sides of the conversation, as though it were a simple factual prediction — how long will this take — when in practice it functions as the opening move in a negotiation with several genuinely adjustable variables: scope, quality, staffing, and timeline. Treating an estimate as a single fixed number to hit, rather than as one point in a negotiation over which of those variables can flex, tends to produce exactly the pattern the Clean Coder guide discussed elsewhere on this shelf identifies as unprofessional — agreeing to a number that was never realistic, and discovering the mismatch only once it's much more expensive to address. A practical estimation overview is available in the Atlassian guide to agile estimation.
The variables that are actually negotiable
When a deadline and a scope both feel fixed and non-negotiable, it's worth noting explicitly that at least one of the classic constraints — scope, timeline, staffing, or quality — is nearly always more flexible than it initially appears, even if the conversation hasn't made that flexibility explicit yet. A tight deadline might be genuinely fixed (a contractual date, a regulatory requirement) or might be a preference that hasn't yet been tested against its actual cost; the difference matters enormously for how the conversation should go, and asking directly which category a given deadline falls into is often a more useful first move than immediately trying to figure out how to hit it as stated. Capacity estimates should begin with realistic annual availability, and https://www.monitask.com/blog/how-many-work-hours-are-in-a-year-of-full-time-work/ provides a practical baseline.
Presenting options explicitly — here's what's achievable by the stated date with reduced scope, here's what full scope would require in additional time, here's what additional staffing could realistically buy given ramp-up costs discussed in the mythical-man-month guide elsewhere on this shelf — shifts the conversation from a single yes-or-no answer to a genuine trade-off decision, which is usually a decision the requesting stakeholder is actually well positioned to make once the trade-offs are made concrete, even if they weren't well positioned to generate a realistic estimate themselves.
Why padding an estimate isn't the same as this negotiation
A common, understandable response to repeated pressure on estimates is padding — privately inflating every estimate to create a hidden buffer against the pressure to compress it later. This tends to backfire in a specific, predictable way: once padding becomes a known or suspected pattern, estimates lose credibility on both sides, and the negotiation shifts to an adversarial guessing game about how much padding is baked into any given number, rather than an honest conversation about real trade-offs. Explicit, honest estimation — ideally as a range reflecting genuine uncertainty, paired with an openly stated confidence level — tends to hold up better over time than a padded number that both sides have learned not to fully trust.
- Treat an estimate as one move in a negotiation over scope, timeline, staffing, and quality — not a single number to defend or comply with in isolation.
- Ask directly whether a stated deadline is genuinely fixed or a preference that hasn't been tested against its real cost — the answer changes what kind of conversation is actually needed.
- Present trade-offs concretely (reduced scope by this date, full scope by this later date) rather than a single yes-or-no answer to an unrealistic ask — it gives the requester a real decision to make.
- Avoid padding as a substitute for this conversation — it erodes trust in estimates over time in a way that honest, explicit uncertainty doesn't.
Why this is a skill worth deliberately building
Very few engineers receive explicit training in this kind of negotiation, despite it being a near-universal part of the job — most learn an ad hoc version of it through repeated, sometimes painful experience, rather than through any deliberate skill-building. Treating it explicitly as a learnable skill, the way the writing and communication skills discussed elsewhere on this shelf are treated, tends to produce a more consistent and less individually stressful version of a conversation that otherwise gets relearned from scratch, imperfectly, by each engineer independently.
Read alongside the RFC-writing guide discussed elsewhere on this shelf, this is really the same underlying discipline — making implicit trade-offs explicit and legible — applied specifically to the moment a deadline gets proposed, rather than to a technical design decision.