“When will it be done?”
It is a reasonable question. Your organization coordinates releases, customer commitments, and budget cycles around answers to it. The people asking are not being unreasonable.
The problem is that software estimates under genuine uncertainty cannot always be both honest and precise at the same time. When you are asked to commit to a date on work that is not yet fully understood, the pressure to sound confident tends to win over the pressure to be accurate.
What follows from fake precision is predictable. The number gets locked in. The work turns out harder than it looked. The date slips. And instead of a conversation about updated information, you have a conversation about why you missed.
The reframe that helps: treat the answer to “when will it be done?” as a translation problem, not a commitment problem.
Developers think in complexity and uncertainty. Managers and stakeholders think in calendar and outcomes. Neither framing is wrong. Neither is fully legible to the other. Your job is to render one into the other without inventing confidence you do not have.
A useful answer structure: here is what we know, here is what we do not yet know, here is the range if nothing significant changes, and here is what I will tell you immediately if it shifts. That is not hedging. It is treating the estimate as a running conversation rather than a one-time transaction.
Stakeholders who receive honest uncertainty early — including the uncomfortable parts — tend to ask fewer anxious follow-up questions. They stop polling daily because they trust they will hear about changes before they have to ask.
The goal is not to avoid giving a date. It is to give a date that is connected to the actual state of the work, with a clear commitment to update it as that state changes.
Fake precision feels safer in the moment. It almost always costs more later.
Chapter 10 of Surviving Agilefall covers the full managing-up toolkit. Also available DRM-free on Gumroad.