I once watched a senior developer tell a room full of stakeholders that a feature would take “about two weeks.” He said it with the kind of confidence you usually reserve for knowing your own name. Eight weeks later, the feature shipped, and the stakeholder trust wasn’t just bruised—it needed a full-body cast. The problem wasn’t incompetence. It was that he’d offered a guess dressed up in estimation clothing, and nobody in the room knew the difference.
If you’ve ever been on the wrong end of a deadline you “estimated,” this one’s for you. No frameworks, no certification jargon. Just the scar tissue I’ve collected so you can collect a little less.
The Telltale Heart of a Guess
A guess is what happens when someone asks “how long?” and your brain, desperate to be helpful, coughs up a number based on vibes. You picture the happy path. You imagine yourself at peak productivity, uninterrupted, with no legacy code surprises. That number feels real because you want it to be real. It rarely is.
Guesses sound like this in the wild:
- “Shouldn’t take more than a few days.”
- “Probably similar to the last one.”
- “I’ll just say a week to be safe.” (Narrator: It was not safe.)
Guesses are emotional. They’re tied to your desire to seem competent, to avoid conflict, or to just end the meeting so you can get back to actual work. They skip the messy middle—the database migrations that fail silently, the library that’s two major versions behind, the stakeholder who will absolutely change their mind on day three.
The real danger isn’t that a guess is wrong. It’s that once you say it out loud, it calcifies. The listener hears “estimate,” and that number gets etched into a project plan, a contract, or a promise to a client. You didn’t estimate. You just made a wish.
What an Estimate Actually Asks of You
An estimate is a prediction built on interrogated uncertainty. It doesn’t claim to be prophecy. It says: “Based on what I know, what I’ve seen before, and what I’m explicitly assuming, here’s a range of outcomes, and here’s how confident I am about that range.”
That’s a mouthful. Let’s break it into the parts that matter when you’re staring at a Jira ticket.
1. You Anchor It to Something Concrete
An estimate needs a reference class—something similar we actually measured. If you’re building a login screen and you’ve built three before, you don’t pull a number from the air. You pull the actual hours from the last one, then adjust for what’s different this time. No history? Then you’re not estimating—you’re guessing, and you need to say that out loud.
I keep a personal log of how long common task types take me, not to bill clients, but to stop my own brain from lying to me. When I see that the last three API integrations took 18, 23, and 26 hours of focused work, “about a week” starts to look irresponsible.
2. You State Your Assumptions Like You’re Under Oath
Every estimate is a stack of assumptions wearing a trench coat. The trick is to list them before someone else discovers them at the worst possible moment. “This assumes the third-party API docs are accurate. This assumes the database schema doesn’t need a refactor. This assumes Karen from marketing won’t ask for a complete redesign on Thursday.”
When an assumption breaks—and one always does—you don’t have to apologize for being “wrong.” You point to the assumption that no longer holds and say, “The estimate changes because the ground moved.” That’s not failure. That’s engineering.
3. You Deliver a Range, Not a Date
Single-point estimates are lies we tell to make schedules look tidy. Real work follows a distribution. My estimates now sound like: “Based on similar work, 3 to 5 days is likely. There’s a small chance it goes to 8 if the authentication layer needs retooling.”
This terrifies people who want certainty. But giving them a false date and missing it erodes trust far more than an honest range up front. I’ve learned to say, “If you need a single date for a contract, take the high end of my range and we’ll talk if things go better than expected.”
Why We Keep Guessing Even When We Know Better
If the difference is so clear, why do smart engineers keep guessing? Because the system often rewards it.
Say you give a thoughtful estimate with assumptions and a range. Your colleague says, “Two weeks, easy.” The manager visibly relaxes. The stakeholder nods. You look like the difficult one, the overthinker. In the short term, the guess wins the social game. Six weeks later, when the colleague’s feature is still in QA, nobody remembers who said what—they just remember the project is late. The social reward for guessing is immediate; the penalty is deferred. That’s a trap laid by our own psychology.
Another culprit is optimism bias, and engineers are saturated with it. We solve hard problems for a living, so we tend to believe the next hard problem will yield to our brilliance on schedule. It won’t. The bug you don’t know about yet doesn’t care about your self-image.
Practical Ways to Drag Yourself from Guessing to Estimating
I’m not going to tell you to adopt a whole methodology. Here are three habits that have kept me mostly honest.
Separate Sizing from Duration
Many teams get mileage out of relative sizing—saying “this task feels about twice as big as that reference task” rather than “this will take 14 hours.” Removing the clock from the first conversation short-circuits the brain’s urge to please. You can translate size to duration later, using your team’s historical velocity. If you don’t have historical velocity, you’re not ready for duration estimates at all, and admitting that is a form of professional integrity.
Pre-Mortem the Task
Before committing to a number, spend five minutes imagining the feature has already failed and shipped six weeks late. Write down what killed it. Was it an untested dependency? A misunderstood requirement? A key person going on leave? Those are your assumptions and risks. Now go back and adjust your estimate to account for the most probable killer. This feels pessimistic, but it’s just pattern recognition with extra steps.
Track Your Hit Rate, Not Your Wins
For three months, I kept a stupid-simple spreadsheet. Column A: my initial estimate range. Column B: actual time. I didn’t do this to shame myself. I did it to see how I was wrong. I learned I consistently underestimated anything involving CSS by a factor of two. I learned I never accounted for code review lag. I learned my “small chance” scenarios happened about 30% of the time. Data beats self-confidence every time.
When a Guess Is Actually Acceptable
I’m not saying you can never guess. Sometimes a stakeholder needs a gut check to decide whether to pursue an idea at all. In that case, frame it explicitly: “This is a rough order-of-magnitude guess, not an estimate. I’d put it in the weeks-to-months category, but I haven’t looked at the code yet.”
The key is the label. Call a guess a guess, and it can be useful. Call a guess an estimate, and you’ve just signed a contract you didn’t read. I’ve started using the phrase “confidence level” in these conversations. “My confidence in this number is low because I haven’t touched that module.” People respect the honesty more than they resent the ambiguity.
The Part Nobody Talks About: Estimates Are a Social Contract
An estimate isn’t just a technical artifact. It’s a promise about how you’ll communicate. When I give an estimate now, I also say: “I’ll update you in three days if anything changes my range.” That tiny clause does more for trust than any project management tool. It tells the other person that the estimate is a living thing, not a stone tablet.
If you work somewhere that punishes you for updating an estimate, you don’t have an estimation problem. You have a culture problem. And no article can fix that—but recognizing it can help you decide where to invest your career energy.
FAQ
What’s the quickest way to tell if I’m guessing instead of estimating?
Ask yourself if you’d be willing to bet a meaningful amount of your own money on the number. If the thought makes you sweat, you’re guessing. Also, if your “estimate” is a single number with no stated assumptions, it’s almost certainly a guess in disguise.
How do I explain estimation uncertainty to a non-technical manager?
Use a commute analogy. “If I leave at 8 a.m., I usually arrive between 8:25 and 8:40. If there’s an accident, it could be 9:00. I’m giving you the usual range. If you need me there by 8:30 sharp, we need to talk about leaving earlier or accepting the risk.” Most people intuitively understand ranges in daily life; we just forget to apply them to software.
Should I pad my estimates to protect myself?
Padding is just guessing with a safety blanket. It erodes trust when discovered and doesn’t address the root issue—unidentified assumptions. Instead of padding, explicitly list your assumptions and give a range. The high end of an honest range serves the same protective function without being deceptive.
What if my team has no historical data to base estimates on?
Then you can’t estimate with any meaningful accuracy, and pretending otherwise is dangerous. Start by tracking time on your current work immediately. In the interim, use relative sizing (this task feels 3x bigger than that task) and communicate that your duration translations are experimental. Honesty about ignorance is a form of credibility.
The line between guessing and estimating isn’t about math. It’s about whether you’ve done the work to separate what you know from what you’re assuming. Do that, and the numbers that come out will still be wrong sometimes—but they’ll be wrong in ways you can explain, learn from, and eventually, start to anticipate.