Delivery & Execution

Why Engineering Estimates Are Always Wrong — and What to Do Instead

Estimates aren't wrong because your team is bad at them. They're wrong because of how estimation works. Stop chasing accuracy and start managing uncertainty.

Engineering Management Academy3 min read

Every engineering manager has lived this story. The team estimates two weeks. Leadership hears two weeks. Four weeks later, the feature ships, and everyone is quietly disappointed — including the engineers, who genuinely believed in the original number.

The instinct is to fix the estimates: more detail, more padding, more process. But the problem isn't that your team is bad at estimating. The problem is that estimation is fundamentally an exercise in predicting the unknown — and no amount of process turns the unknown into the known.

The managers who deliver predictably aren't the ones with accurate estimates. They're the ones who stopped treating estimates as promises and started managing uncertainty directly.

Why estimates are structurally unreliable

Three forces guarantee that estimates drift:

  • The cone of uncertainty. At the start of any project, you know the least you will ever know about it. Early estimates can be off by 4x in either direction — not because of incompetence, but because the work hasn't been discovered yet.
  • Hidden work. The actual coding is often the small part. Integration, edge cases, code review, flaky tests, the dependency that turns out to be undocumented — these dominate real timelines and resist estimation.
  • Optimism bias. Engineers estimate the happy path because the happy path is what they can picture. Everything that might go wrong is, by definition, harder to imagine than the thing going right.

If you accept these as permanent features of the work rather than bugs in your team, your whole approach changes.

Manage uncertainty, not estimates

Here's what high-performing teams do instead of chasing a perfect number.

1. Estimate ranges, not points

A single number ("5 days") communicates false precision. A range ("3–8 days, most likely 5") communicates the actual shape of your confidence. Stakeholders can plan around a range; they get burned by a point.

2. Reduce uncertainty before committing

If something is too fuzzy to estimate, that's information. Spend a timeboxed spike to de-risk the unknown part before you commit to a date. A day of investigation that turns a 4x uncertainty into a 1.5x uncertainty is the highest-return work you can do.

3. Track flow, not just estimates

Cycle time — how long work actually takes from start to done — is a far better predictor than estimates, because it's based on your team's real history rather than its hopes. If your stories typically take 3–10 days regardless of their estimate, that's your planning data.

4. Slice smaller

Large estimates are always less accurate than small ones, and the error compounds. Work broken into pieces that each take a day or two is both easier to estimate and easier to course-correct. Small slices also let you ship value continuously instead of betting everything on one big delivery.

Communicating up the chain

Most of the damage from bad estimates happens not in engineering but in the translation to stakeholders. A few principles protect you:

  1. Never let a range become a deadline by accident. If you say "3–8 days," someone will write down 3. State your planning assumption explicitly.
  2. Separate the estimate from the commitment. "Our best estimate is X. What we can commit to is Y." The gap between them is your buffer against uncertainty — and naming it builds trust rather than eroding it.
  3. Re-forecast openly. When you learn something that changes the timeline, say so immediately. A surprise four weeks in is a failure of communication, not estimation.

The real skill is judgment under uncertainty

Notice that none of this is about estimating better. It's about prioritisation, sequencing, de-risking, and honest communication — the judgment that turns an unpredictable process into a trustworthy one.

That judgment is exactly what the Delivery & Execution domain of the EMA Competency Framework assesses: not whether you can produce a number, but whether you can deliver reliably when the number is uncertain. It's a capability that compounds across every project you'll ever run.

Curious how your delivery judgment holds up under realistic pressure? EMA-I puts you in scenarios where the deadline is slipping and the trade-offs are real — and scores how you decide.

Test your judgment, not your recall.

EMA-I is a scenario-based exam — free during the founding cohort.

Start EMA-I — Free →