It's not just your engineering team- everyone is bad at estimating.
Estimate less, iterate more.
You’re reading Playbooks & Priorities, a newsletter about working, parenting, and working parenthood.
There’s a running joke in tech: ask an engineer how long a project will take, and you’ll get a number that might as well have been pulled out of thin air. You have better luck nailing your parlays on Draft Kings. Every engineer I’ve ever met—even the best of the best—is bad at estimating how long it will take to get something done. But this isn’t just an engineering problem. It’s a human problem.
Think about it: if estimating work accurately were easy, HGTV would have to find a new formula for its shows. Every single home renovation episode has the same storyline: initial optimism, unforeseen problems, slipped deadlines, a blown budget, and a final mad dash to get the project done. It’s a reminder that underestimating the time, effort, and complexity of work is a universal trait—not just something unique to software development.
So why are we all so bad at this? And more importantly, what should we do about it?
Why Estimating Is So Hard
There are plenty of reasons why estimating work is inherently difficult. Here are a few that stand out:
1. We Only Think About the Happy Path
When estimating, we instinctively focus on how things should go. We imagine a world where every dependency is resolved on time, where no unexpected issues arise, and where everyone involved has a clear understanding of what needs to be done. It’s a nice vision… but it’s rarely the reality.
For example, an engineer might say, “Building this feature will take two weeks.” That’s assuming no one gets pulled into a high-priority bug fix, the requirements don’t change mid-sprint, nobody takes a vacation, and all third-party integrations work flawlessly. Spoiler: none of those assumptions hold up in the real world.
2. We Don’t Plan for Interruptions
No matter how disciplined a team is, interruptions happen. Meetings get scheduled, bugs are discovered, and critical emails demand responses. These distractions chip away at the time available for deep, focused work, yet they’re rarely accounted for in initial estimates.
Consider a team tasked with redesigning an onboarding flow. They estimate it’ll take a month. Then, halfway through the project, a production issue pulls half the team away for a week. Suddenly, that one-month timeline looks unrealistic—but was it ever realistic to begin with?
3. We Fail to Expect Edge Cases
Work often gets complicated in ways we don’t foresee. Edge cases—those rare but inevitable scenarios—pop up and demand attention. They’re hard to anticipate, but they’re also a regular part of the job.
For instance, imagine a team implementing a new payment gateway. They might plan for common use cases but overlook the edge case where a user tries to pay with an expired card in a currency the system doesn’t support. Handling that scenario might require additional engineering work, QA testing, and even changes to the design.
The Wrong Question
Beyond these challenges, there’s another fundamental issue: we’re asking the wrong question.
When we ask engineers to estimate how long it will take to build something, it’s like asking a contractor how long it will take to build a house. The answer—“Six months”—might sound reasonable, but it’s too vague to be actionable. What if instead we asked:
How long will it take to pour the foundation?
How long will it take to install the subfloor?
How long will it take to tile the bathroom?
Breaking work down into smaller chunks not only makes estimates more accurate but also surfaces potential risks earlier. A delay in tiling the bathroom doesn’t derail the entire project—it’s just one piece of the puzzle.
A Better Approach to Estimation
If everyone is bad at estimating work—and they are—then perhaps it’s time to stop relying so heavily on estimates. Instead, we should embrace a few key principles:
1. Estimate in the Smallest Possible Chunks
Rather than asking how long it will take to complete a major project, focus on estimating individual tasks. The smaller the chunk, the easier it is to estimate accurately.
Example: Instead of estimating “Build the new user dashboard,” break it down into tasks like “Create API endpoints for dashboard data,” “Design the front-end layout,” and “Integrate API with the front end.” Each task can then be estimated independently.
2. Focus on Shipping Smaller, More Iterative Changes
Large, monolithic projects are harder to estimate because they involve more variables and dependencies. By breaking work into smaller, incremental changes, teams can deliver value faster while reducing the risk of major delays.
Example: Instead of building an entirely new feature set in one go, a team could ship the MVP first, gather feedback, and iterate based on real-world usage. This approach not only accelerates delivery but also provides more clarity on what to build next.
3. Accept That Estimates Are Guesses
No matter how experienced a team is, estimates will always involve a degree of uncertainty. The goal shouldn’t be perfection—it should be learning from experience and improving over time.
Example: After each sprint, a team could review how their estimates compared to actuals. Were there recurring challenges? Were some tasks underestimated more than others? These insights can inform future planning.
Or flipping estimation on its head
Another method that I’ve used in the past is not estimating how long a project will take, but rather estimating how far you can get in a specific amount of time. I am notorious for asking “but what is the 1-hour version of that?” Because I know that everyone (myself included) is terrible at estimating, I assume that whatever people reply with is actually a 1-day version.
When it comes to “Building a house”, the 1 hour version is “looking up styles of houses on Pinterest” and that might seem futile, but when it comes to improving user experience, that might mean: standardizing capitalization across the app, brainstorming a solution to a problem, or a directionally-correct analysis.
The best approach: Estimate less, iterate more
Given that we’re all terrible at estimating, I think we should try to spend the least amount of time possible on it. As I’m notorious for saying work about work is not work. Let’s minimize the amount of time spent in the liminal state of work about work that makes people feel busy but does not drive value.
Focus instead on iterating small, manageable chunks of work that can create value quickly and collect feedback to decide whether or not it’s worth spending more time on an initiative.
Embracing Reality
At the end of the day, the problem isn’t that engineers are uniquely bad at estimating—it’s that estimating work is inherently difficult for everyone. Instead of fighting this reality, we should adjust our processes to account for it.
By focusing on smaller chunks of work, shipping iteratively, and treating estimates as starting points rather than guarantees, we can build systems that are resilient to the unpredictability of real-world work. After all, the goal isn’t just to hit deadlines—it’s to deliver meaningful outcomes.
So the next time someone complains that their engineering team is bad at estimating, remind them: it’s not just your engineers. It’s everyone. And that’s okay—as long as we’re willing to adapt.