The Meeting That Changed Everything
I remember the exact moment. It was 2023, and I was on a Zoom call with three product managers, two designers, and our CTO. "So, how long will this authentication integration take?" someone asked. I took a deep breath, glanced at the incomplete requirements document, and said what I thought they wanted to hear: "Maybe two weeks?"
Three months later, we were still untangling OAuth flows, rate limiting issues, and edge cases we hadn't anticipated. The feature shipped late, the team was burned out, and I'd learned a painful lesson about estimation theater.
That's when I made my rule: I never estimate on the call. Not ever. Not for small features, not for bug fixes, not even for "quick questions." And in the three years since adopting this practice, it's become the single most valuable engineering rule I've established for myself.
Why On-the-Spot Estimates Fail
Let's start with the obvious question: What's so bad about giving a quick estimate during a meeting? After all, we're professionals—shouldn't we have a rough sense of how long things take?
Here's the problem: Estimation isn't about guessing. It's about analysis. When you're put on the spot during a call, you're missing critical information:
- You haven't seen the code you'll be working with
- You don't know about dependencies that might block you
- You're missing context about recent changes to the codebase
- You're being influenced by the social pressure of the meeting
One engineer in the original discussion put it perfectly: "When someone asks for an estimate on a call, they're not asking for accuracy. They're asking for commitment. That number becomes the deadline, regardless of what you actually said."
And here's the kicker—people remember the optimistic version. Say "2-4 weeks" and they'll hear "2 weeks." Mention "a few days" and suddenly it's on tomorrow's status report.
The Psychology of Estimation Pressure
There's a psychological dynamic at play here that most engineers don't recognize until they've been burned multiple times. When you're asked for an estimate during a meeting, several things happen simultaneously:
First, there's the anchoring effect. The first number mentioned—even if it's labeled as a "rough guess"—becomes the anchor for all future discussions. If you say "maybe a week" during that initial call, any subsequent analysis suggesting three weeks will be met with resistance. "But you said a week earlier!"
Second, there's social pressure to be helpful. You're in a room (virtual or physical) with stakeholders who need answers. Saying "I don't know" feels unprofessional, even though it's often the most professional response available. So you give a number to move the conversation forward, sacrificing accuracy for social comfort.
Third, and this is crucial: estimation requests are rarely about planning. They're about scheduling. The product manager needs to know when to announce the feature. Marketing needs a launch date. Sales wants to promise it to clients. Your estimate isn't being used to plan work—it's being used to make promises to other parts of the business.
Once you understand this dynamic, you realize why protecting the estimation process matters. It's not about being difficult—it's about ensuring the business makes realistic commitments.
What "I'll Get Back to You" Actually Means
So what do you actually say when someone asks for an estimate during a call? My go-to response has evolved over the years, but it generally follows this pattern:
"That's a great question. Let me take a look at the existing code and dependencies, and I'll give you a proper analysis by [specific time]."
Notice what this does:
- It acknowledges the question as valid (because it is)
- It sets the expectation that estimation requires investigation
- It provides a concrete timeline for when you'll deliver the estimate
- It moves the conversation forward without giving a number
Some engineers worry this makes them look unprepared. In my experience, it does the opposite. Stakeholders start to recognize that when you do give an estimate, it's reliable. You build trust through accuracy, not through speed.
One commenter in the original thread shared their variation: "I tell them I need to 'spike it' first. That's become code in our organization for 'I need to actually look at this before giving numbers.' It's worked wonders."
The Proper Estimation Process (What Happens After the Call)
Okay, so you've deferred the estimate. Now what? This is where the real work happens—and where most teams cut corners. Here's my actual process, developed through trial and error:
Step 1: Code investigation. I actually look at the relevant code. How messy is it? When was it last touched? Are there tests? This alone can change an estimate by 100%.
Step 2: Dependency mapping. What other systems does this touch? Do I need changes from other teams? Are there API rate limits or authentication hurdles?
Step 3: Historical comparison. I look at similar work we've done recently. How long did it actually take versus what we estimated? This historical data is gold—most engineers never build this reference library.
Step 4: Three-point estimation. I give best case, likely case, and worst case scenarios. The key: I always share all three numbers, not just the middle one. This helps stakeholders understand the range of possibilities.
Step 5: Document assumptions. Every estimate comes with a list of assumptions. "This assumes the API documentation is accurate" or "This assumes no major refactoring is needed." When assumptions change, the estimate changes.
This process takes time—anywhere from 30 minutes to several hours for complex features. But compare that to the weeks of missed deadlines and overtime that come from bad estimates, and it's clearly worth the investment.
Handling Pushback from Stakeholders
You'll get pushback. Especially from people used to getting immediate answers. Here's how I handle common objections:
"But I just need a rough idea!"
My response: "I understand, and I want to give you a useful answer. My rough ideas have been wrong too many times to be helpful. Let me give you something accurate instead."
"Can't you just give me a ballpark?"
"The problem with ballparks is they become stadiums. Let me do this properly so we're both working with good information."
"Other engineers give me estimates right away."
This one's tricky. I usually say: "Different approaches work for different people. My approach is to ensure the estimates I give are reliable, even if they take a bit longer to produce."
The key is consistency. Once you establish this as your process—not as an exception but as your standard way of working—people adapt. They start planning meetings differently. They send requirements ahead of time. The culture shifts.
Tools That Actually Help with Estimation
While the human process is most important, some tools can genuinely help. I'm skeptical of most estimation software (they tend to promise more than they deliver), but a few approaches have proven valuable:
Historical tracking. This is the single most useful tool. We use a simple spreadsheet where we record: initial estimate, actual time, what went wrong/right, and key learnings. After a year, you have your own data set about how your team actually works.
Planning poker cards. Not for the poker part, but as a physical reminder that estimation should be deliberate. Having the cards on the table signals "we're estimating now" versus "we're casually chatting."
Time tracking software. Not for micromanagement, but for gathering data. We use it anonymously and aggregately to understand how long different types of tasks actually take.
One interesting suggestion from the discussion: Use API monitoring tools to understand integration complexity. If you're estimating API work, tools that show you actual response times, error rates, and documentation quality can dramatically improve estimates. Services like Apify can help you understand external APIs before you commit to timelines.
For teams just starting with proper estimation, I often recommend Software Estimation: Demystifying the Black Art. It's been around for years, but the principles are timeless.
When Breaking the Rule Makes Sense
Like all good rules, this one has exceptions. After three years of never estimating on calls, I've identified exactly two situations where I might give an immediate estimate:
1. Trivial, repetitive tasks. If it's something I've done dozens of times before in this exact codebase—like adding a new field to an existing form—and I can literally see the code in front of me, I might give an immediate estimate. But I'm careful with this. "Trivial" is often an illusion.
2. Production emergencies. When the site is down and we need to know if a fix is "minutes or hours," that's different. But even then, I'm clear about the uncertainty: "Based on what I can see right now, I think it's about two hours, but that could change as I dig deeper."
The common thread: transparency about uncertainty. Even when giving quick estimates, I'm explicit about what I don't know.
Transforming Your Team's Estimation Culture
This isn't just an individual practice—it's a cultural one. When I started refusing to estimate on calls, something interesting happened: other engineers started doing it too. We developed shared language and processes.
Now, when someone asks for an estimate during a meeting, multiple engineers will say some variation of "Let's spike that first" or "I need to check the dependencies." It's become our team norm.
We've also changed how we run planning meetings. Requirements go out at least 24 hours in advance. Engineers come prepared with initial investigations already done. Estimation becomes a separate agenda item, not something that happens incidentally.
The result? Our estimation accuracy has improved dramatically. We're not perfect—estimation is inherently uncertain—but we're rarely off by more than 20-30% anymore. Compared to the 200-300% misses we used to have, that's transformative.
FAQs from Engineers Trying This Approach
In the original discussion, engineers had practical questions about implementing this rule. Here are the most common ones with my answers:
Q: What if my manager insists on immediate estimates?
A: Have the conversation offline. Explain why accurate estimates matter for the business's ability to make realistic commitments. Frame it as helping them do their job better, not as refusing to cooperate.
Q: How do I estimate without sounding like I'm stalling?
A: Provide immediate next steps instead of an estimate. "I'll investigate the authentication service and have an estimate by 3 PM today" is proactive, not evasive.
Q: What about agile teams that estimate in sprint planning?
A: This approach works beautifully with agile. The difference is that sprint planning is specifically for estimation—you have the right context, the right people, and the right preparation. It's the impromptu estimation during other meetings that causes problems.
Q: Won't this slow everything down?
A: Counterintuitively, it speeds things up. Less rework from rushed estimates, fewer emergency fixes from cutting corners, and more predictable delivery. The initial time investment pays for itself many times over.
The Real Benefit: Sustainable Engineering
Here's what surprised me most about adopting this rule: it changed how I feel about my work.
Before, estimation was a source of constant stress. I'd give a number, then immediately regret it. I'd spend meetings mentally calculating how I could possibly deliver in that timeframe. I'd work nights and weekends to meet commitments I knew were unrealistic when I made them.
Now, estimation is a technical process. It's about analysis, not anxiety. I investigate, I analyze, I document. The estimate is the output of a process, not a personal promise.
And something else happened: my estimates became more accurate. Not because I got smarter, but because I gave myself permission to do the work estimation actually requires.
One engineer in the discussion captured this perfectly: "The day I stopped estimating on calls was the day I stopped being perpetually behind. I'm still busy, but I'm not constantly cleaning up my own rushed estimates anymore."
Your First Step
If you're convinced but not sure where to start, here's my suggestion: Pick one meeting next week where you know someone will ask for an estimate. Prepare your response in advance. Practice saying it out loud if you need to.
When the question comes, take a breath and say: "That's a good question. Let me look at the code and dependencies, and I'll give you a proper estimate by end of day."
Notice what happens. Notice how you feel. Notice the reaction.
For most engineers, that first time is uncomfortable. The second time is easier. By the third time, you start to feel professional instead of evasive. And within a month, you'll wonder how you ever worked any other way.
Estimation isn't about guessing. It's about understanding. And understanding takes time—time we rarely give ourselves during meetings. By refusing to estimate on calls, you're not being difficult. You're being professional. You're ensuring that when you do give a number, it means something.
In 2026, with development cycles getting faster and systems getting more complex, this distinction matters more than ever. The pressure for quick answers will only increase. Our responsibility as engineers is to provide good answers instead.
Start tomorrow. The next time someone asks for an estimate on a call, pause. Take a breath. And say the words that will change how you work: "Let me get back to you with a proper analysis."
Your future self—and your team—will thank you.
