You Asked for an Estimate. You Started a Three-Day Debate.

You’re in the room—real or virtual. The team is assembled. You’ve just finished walking through the new feature, a beautiful solution to a well-documented user problem. You feel good. You feel clear. Then you ask the question.

“So… any rough idea how long this might take?”

The silence is immediate. One engineer stares at the ceiling. Another starts typing furiously, probably not about your feature. The tech lead un-mutes. “Well, that depends. Are we talking about the iOS app or Android? Does this need to integrate with the legacy payment service? What do you mean by ‘done’?”

The next hour is a blur of edge cases, architectural debates, and laments about tech debt. Your simple question has spiraled into a philosophical discussion. No estimate is given. The team leaves frustrated, and you have nothing to take back to your stakeholders.

The problem wasn't the team's reluctance. The problem was your question. You didn't ask for an estimate; you asked for a commitment without providing the necessary context.

Why the “How Long?” Question Backfires

Asking for a raw number puts your engineering team on the defensive. They’ve been burned before. A "rough estimate" they gave in a meeting somehow became a "firm deadline" on a GANTT chart three months later.

This single question fails for three reasons:

1. It implies a promise. Engineers don't hear "guess." They hear "deadline." They immediately start padding for every conceivable risk, because they know that number will be anchored in everyone's mind, stripped of all its original caveats.
2. It ignores uncertainty. Meaningful software development is a process of discovery, not a predictable assembly line. Asking for a single number pretends all the questions have been answered, when the team hasn't even written a line of code.
3. It assumes a shared understanding. You have a crisp image of the feature in your head. But does the engineer? Does the designer? Without a shared, tangible artifact to point to, everyone is estimating a different movie.

The goal isn't to get a number. The goal is to understand the complexity and risk.

Better Questions That Build Alignment

Instead of asking for a number, you need to start a conversation. Your job is to facilitate a shared understanding of scope and complexity. Try these questions instead.

“What’s the t-shirt size on this? S, M, L, XL?”

This is the classic way to shift from absolute time to relative effort. It’s less threatening. Nobody gets held to a "Medium" the way they get held to "three weeks."

• Why it works: It’s a tool for categorization, not commitment. It quickly surfaces misalignment. If you think something is a Small and the team says it's an Extra Large, you don't have an estimation problem. You have a scope problem. Now you can have the right conversation: “Interesting, I was thinking this was much smaller. What am I missing?”

“What are the biggest risks or unknowns here?”

This question moves the focus from time to discovery. It invites the team to be your partner in de-risking the project.

• Why it works: It turns engineers into problem-solvers. They can point out dependencies on other teams, brittle legacy code, or ambiguous requirements. The output isn't a date; it's a list of action items. Maybe you need to schedule a meeting with another team or the lead engineer needs to write a one-page spike plan to investigate a new API. This is infinitely more valuable than a premature guess.

“What’s the smallest possible version we could ship to solve 80% of the problem?”

This frames the conversation around scope, not just effort. It’s a direct invitation to collaborate on phasing.

• Why it works: It forces prioritization. The team can help you separate the must-haves from the nice-to-haves. This often leads to a much smaller, more manageable first version that can be estimated with higher confidence. It changes the dynamic from "Tell me how long your part takes" to "Let's figure out how to deliver value sooner."

Your Homework Before the Meeting

You can’t just show up with better questions. You have to do the prep work to make them effective. Walking into a planning session with a vague idea and asking for an estimate is disrespectful of the team's time.

Before you ever ask for a size, do this:

• Write a tight problem statement. One paragraph. What specific user problem are we solving? For whom? Why does it matter to the business? Have the data point or user quote that proves it.
• Sketch the user flow. A simple diagram with boxes and arrows on a whiteboard is fine. It makes the abstract tangible. It forces you to think through the steps and gives the team something concrete to react to.
• Define the “happy path.” Write 3-5 bullet points describing what happens when the feature works perfectly for the primary use case. Acknowledge edge cases but explicitly state they are out of scope for the initial discussion.
• Come with a hypothesis. Don't show up with a blank slate. Start the conversation with, "My gut says this is a 'Large' because it touches the checkout service. Does that feel right?" This gives the team a starting point to agree or disagree with.

An estimation discussion isn't a meeting where you extract information. It's a working session where you and the team build a shared understanding of the work ahead. Your job is to bring the materials to make that session productive. The estimate is just the byproduct.