Why 'That'll Take Three Months' Is Always a Guess
Engineering estimates feel precise but they're decompositions of known work plus guesses about everything else. The unknown work is what kills timelines — and developers aren't bad at estimating what they understand, they're systematically bad at knowing what they don't know yet.
1:16
Transcript
Your engineer said three months. It's been five. They weren't lying — they were guessing. Every estimate is a decomposition of known work plus a guess about the unknown work. The unknown work is what kills the timeline.
When a developer gives you a number, here's what they're actually doing. They're listing the tasks they can see — implementation, integration, debugging, coordination. They're adding those up. But the tasks they can't see yet? Those don't make the list. That's the problem. Unknown unknowns don't get estimated because they're unknown.
Look at how actual delivery compares to estimates across project types. A simple, well-understood feature? Around 1.4x the estimate — because the scope was clear. A new third-party integration with undocumented APIs? 2.3x. A new system with shifting requirements? 3.1x. The more unknown unknowns, the further the estimate drifts. Not because your team is slow. Because the estimate was never measuring the right thing.