Someone asks how long a task will take and you say three days. The number sounds like a fact, and it’s treated as one — it goes on a plan, other people’s work gets scheduled around it, a commitment forms. But the honest version of that answer was never a single number. It was a range with a shape: probably three days, could be two if things go smoothly, could be nine if the part you haven’t looked at yet turns out to be the hard part. Collapsing that into “three” doesn’t make the uncertainty go away. It just hides it from everyone who now depends on the number, including you.

The reason single-point estimates mislead so reliably is that software estimates aren’t symmetric. A task almost never finishes dramatically early — there’s a floor, the fastest it could possibly go if everything breaks your way, and you’re usually already near it in your guess. But there’s no ceiling. The unknowns only ever add time: the API that doesn’t behave like the docs, the migration that’s slower than expected, the requirement that was hiding a second requirement inside it. So the distribution has a long tail to the right, and the single number you say sits near the optimistic front of it, because you’re estimating the path where nothing surprising happens — and something surprising almost always happens.

This is why “just add a buffer” doesn’t really fix it. Padding a number keeps the fiction that there’s a number; it just makes it a bigger one, chosen by feel, that still hides the shape. What actually helps is communicating the shape itself — not “three days” but “probably three, but there’s a chunk I haven’t investigated that could push it to two weeks, and I’ll know which world we’re in after a day of looking.” That sentence is more useful than any single figure, because it tells the person planning around you what the risk is and where it lives, and it points at the cheapest thing anyone can do about it: reduce the uncertainty before committing.

That’s the move the distribution framing actually unlocks. If most of your spread comes from one unexamined part, the highest-value thing you can do isn’t to estimate harder — it’s to spend a little time collapsing that part’s uncertainty. Spike the risky integration for an afternoon. Read the code you’re about to depend on. Build the thin end-to-end slice that proves the shape works before you commit to the whole. Each of these narrows the distribution, which is worth far more than refining the point estimate, because the point was never the problem — the width was. An estimate you can tighten by investigating is a question in disguise, and the investigation is usually cheaper than being wrong.

None of this means never giving a number; people need something to plan with, and “it depends” helps no one. It means treating the number as the summary of a distribution you actually hold in your head, and being willing to say the rest out loud — how confident, driven by what unknowns, tightened by what investigation. The people who estimate well aren’t the ones with a gift for guessing the right single figure. They’re the ones who know which parts they don’t understand yet, say so, and go find out before the guess becomes a promise.