Inaccurate remaining-time estimates damage trust

What it is

“1 minute left” is not decoration. It is a promise. People allocate attention against it: keep watching, go pour water, cancel. When the estimate stays wrong — always “almost done” and never done, or leaping from two minutes to twenty and back to thirty seconds — what breaks is not the mood of this wait. It is trust in every remaining-time figure that will follow. This leaf is about that broken trust, not about which estimator to use. An estimator can be sophisticated and still kill predictability at the trust layer if it is repeatedly falsified as a promise.

Why it happens

Remaining time collapses an uncertain wait into a number people can decide with. Once the decision is made (wait a bit more, switch away), they score it against the actual arrival. Failure comes in two flavours, and they hurt differently. Optimistic bias (always shorter than reality) creates missed deadlines; people feel hurried and then cheated. Large jumps (the same job’s number thrashing) create an unmodelable system; people feel the product itself does not know. After a couple of rounds the number drops from “decision input” to “noise”, and a later accurate estimate will not be used either. That is a calibration failure: not anger at this wait, but the channel being shut.

If the percent is still rising and only the clock beside it is lying, the damage lands cleanly on the time channel — people start reading the bar and ignoring the clock. If bar and clock thrash together, the bar is implicated too. Fake determinate progress is a cousin in another group; the cousin here is narrower: an honest bar with a dishonest clock.

Studying it

Give the same objective job an optimistic, pessimistic, accurate, or absent remaining-time display, then watch how people decide to stay or leave, and whether they trust a new number on the next wait.

Independent variables: direction and size of estimate error, whether a large mid-job correction occurs, whether cancel or switch-away is allowed. Dependent variables: cancelling too early, staying too late, rate of using the ETA on a subsequent job, trust scales, spontaneous reports that the estimate is noise.

If the lab forbids a stay-or-go decision, trust damage collapses into “annoyance”, which is affect, not calibration. Closer to the ecology: several waits in a row, watching whether eyes still go to the number on round two after round one cheated. Optimistic bias usually hurts more than the same-sized pessimism, because being late is harder to read as the system being cautious than finishing early.

Where it stops holding

When people already know the figure is rough (airports, a disk in weak network, the hedge word “about”), the trust budget is wider — and can still be spent by directional cheating: “about 1 minute” turning into 10 three times in a row will not be saved by the hedge. Giving no remaining time at all is not a broken promise, only a blinder decision; blindness and deceit are different pains. Do not use “we might be wrong” as a permanent excuse to never show a number — honest degradation of the estimate is another group’s problem. Safety-critical countdowns (OTP expiry, lockouts) being wrong is material harm, not only trust. A number is allowed to be revised inside one job; revision itself is not betrayal. Betrayal is a revision that does not look like a revision, just a casual change of story.

Applying it

• Govern remaining time as a promise. If confidence is low, do not present it as a second-precise figure. Once it is on screen, accept that it will be scored.
• Prefer slightly long and then on-time or early over systematically short and then late. A run of broken promises is harder to repair than one overestimate.
• When the number must change, make the correction visible (“network slowed; now about 8 minutes”). Do not silently swap it.
• How to check: run a transfer that will slow down and watch the ETA. If someone leaves on the strength of that ETA and comes back far too early, ask whether they will look at the number next time. If not, the trust channel is already shut.

Related

• Same group: I2.02.1 Progress must be monotonic and must not run backwards · I2.02.2 A long stall needs a stage explanation
• Nearby: I2.10 Remaining-time estimates · E6.09 Determinate and indeterminate progress · I4.06 Countdowns and deadlines
• Search terms: ETA trust · inaccurate remaining time · broken time promise