Ask any developer how they feel about estimates, and you’ll get a sigh, an eye-roll, or an ironic comment: “Estimate” is just another word for “guess”.
Most of them know that, besides trivial or repetitive tasks, accurate estimates don’t really exist. Not for seniors, not for staff engineers, not even for that one developer who knows the system better than anyone.
That’s because whenever a developer builds something, they’re likely doing it for the first time. Even when the task resembles past work, the context is rarely the same: new constraints, new integrations, new UX decisions, new edge cases. There are simply too many variables to foresee, and that gap in knowledge grows exponentially as the scope increases.
Yet the pressure for accurate estimates is high. Managers need predictability to coordinate teams, align priorities, and make commitments beyond the engineering org. As a result, many developers have come to experience estimates as a trap. Underestimate, and you’ll get blamed for delays. Overestimate, and you’ll get questioned, pushed back, or treated as “slow”. Over time, this tension degrades the estimates themselves, turning them into defensive numbers rather than useful signals.
But it doesn’t have to be this way. We can’t predict the future, and insisting that we should only makes things worse. What we can do is work with uncertainty instead of fighting it, and Plan, Adapt, Repeat — treating plans as projections that evolve as we learn, rather than commitments made upfront.
That doesn’t mean abandoning estimates altogether. They’re still needed. But once plans stop being treated as truth, estimates no longer need to be accurate to be useful. That shift alone removes much of the pressure around estimation and restores its real role: helping teams and stakeholders make prioritization and trade-off decisions.
At project, initiative, and roadmap level, rough estimates and relative sizing are usually enough. T-shirt sizes or similar scales help teams compare options, reason about opportunity cost, and decide where to invest attention next — even before diving into details. A “large” initiative doesn’t mean it will take a long time; it means the effort and the risk are high. An “extra-large” one is often a signal that the work needs to be questioned, split, or deferred. There’s no fixed time equivalence, and that’s intentional. Time still matters, of course, but at this level it emerges from capacity and priorities, not from pretending early estimates are precise.
Execution is a different matter. Once a direction is chosen, work can be cut into pieces small enough that developers feel confident about being able to complete them quickly — often within a day or two. At that scale, estimation becomes far more reliable, not because engineers suddenly got better at predicting the future, but because uncertainty has been deliberately reduced. Smaller tasks surface missing decisions early and create tighter feedback loops. That’s where predictability actually starts to exist.
We used to ask estimates to give us certainty, but they never could. An estimate is good if it helps you decide and shape a plan, and whether it turns out to be right at planning time is beside the point. Confidence doesn’t come from being correct upfront; it comes from learning fast once work begins.
Estimates will never be accurate. But when they help us choose wisely, they’re doing exactly what they’re meant to do.