Why Your Estimates Are Always Wrong (And How to Make Them Useful Anyway)

The short answer: Your estimates are always wrong because an estimate isn't a prediction — it's a way to communicate uncertainty. You make it useful anyway by giving ranges instead of single numbers, naming the assumptions the estimate rests on, re-estimating out loud as you learn, and never letting a guess calcify into a promise.

Here is a thing I had to make peace with to stop losing sleep as a technology manager: every estimate I give is wrong. Not sometimes. Always. The question was never "how do I get my estimates right" — that's a losing game — but "how do I make a wrong estimate useful to the people who depend on it."

The trap most engineers fall into is treating an estimate as a prediction. It isn't. An estimate is a communication tool for talking about uncertainty. The number is almost beside the point; what matters is what the number reveals about what you do and don't know.

A single number is a lie of confidence

When someone asks "how long?" and you say "about three days," you've just told them something false — that you're certain enough to commit to a point. You aren't. Three days assumes the API is documented, the designs are final, nobody's out sick, and the thing you've never done before works the way you expect.

So I stopped giving single numbers. I give ranges, and the range is the message:

• "Two to three days" means I understand this well.
• "Three days to two weeks" means there's a chunk I haven't figured out yet, and the honest answer is that the figuring-out is the risk.

A wide range isn't you being wishy-washy. It's you being accurate about your own ignorance. A stakeholder who hears "three days to two weeks" learns something true and plannable: go reduce the uncertainty before you build a launch date on this.

Name the assumptions, because that's where time actually goes

The real work of estimating isn't picking a number — it's surfacing what you're assuming. Nearly every blown estimate I've reviewed in retrospect died on an unstated assumption, not on the coding being hard.

So I write them down, out loud, next to the estimate: "This assumes the payments team's webhook is already live. It assumes we're not also handling refunds in this pass. It assumes the legacy table doesn't need a migration." Half the time, writing the list is enough — a stakeholder reads "assumes the webhook is live" and says "oh, that's not until next quarter," and you've just saved yourself a two-week surprise before writing a line of code.

Decompose until the pieces stop scaring you

The reason a two-week estimate is unreliable is that two weeks of work is a fog. You can't estimate a fog. You can estimate "write the form," "wire the validation," "handle the error states," "add the empty state." When a task is still vague enough that you'd shrug at it, that vagueness is the signal to break it down further — not to slap a bigger number on it and hope.

A pile of small, concrete tasks estimates far more honestly than one large abstract one, because the uncertainty is now visible per-piece instead of smeared across the whole. And the piece you can't break down cleanly? That's your risk. Spike it first.

Re-estimate out loud, early and often

The worst thing you can do with an estimate is let it calcify into a promise and then go quiet. Estimates have a shelf life. The moment you learn the thing is bigger than you thought — the API isn't documented, the design has an edge case nobody specced — you say so immediately. Not at the deadline. The day you learn it.

Delivery management lives and dies on this. A slip you flag three weeks early is a planning conversation. The exact same slip revealed the night before launch is a crisis and a credibility hit. The information was available the whole time; the only variable was whether you shared it when it was still cheap to act on.

Protect the estimate from becoming a deadline

The quiet failure mode is organizational, not technical: an engineer's rough estimate gets repeated up the chain, loses its range and its caveats at every step, and lands on a roadmap as a hard commitment. Nobody lied. The uncertainty just evaporated in transit.

Part of my job is keeping the uncertainty attached to the number as it travels. "The team estimates two-to-four weeks, with the integration being the open risk" is a sentence a VP can actually plan around. "Three weeks" is a sentence that will come back to haunt everyone who repeated it.

Your estimates will keep being wrong. Mine still are. But an estimate that honestly carries its own uncertainty — ranges, named assumptions, early updates — does the one job an estimate actually has: it helps people make good decisions with incomplete information. That's the whole art. The number was never the point.