“Percent complete” is a lie, and “unknown to known to done” is the truth. The bar measures effort and reports it as if it were risk.
There is a joke that every programmer who has ever shipped anything knows in their bones, and it was first written down by a Bell Labs engineer named Tom Cargill and popularized by Jon Bentley in his “Programming Pearls” column in Communications of the ACM in September 1985. It goes: “The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.”
It's funny because the arithmetic doesn't work, and it's true because the arithmetic was never the point. Everyone who has built software has lived this exact curve: the progress bar climbs steadily to 90%, the demo looks basically done, the end is in sight, and then the project spends as long again, sometimes longer, grinding through a “last 10%” that turns out to contain every genuinely hard problem nobody had hit yet. The 90-90 rule is not really a joke about sandbagging, or about discipline, or about engineers being bad at finishing. It's a joke about the progress bar itself. The number was lying. It was measuring something, but not the thing everyone in the status meeting thought it was measuring.
A “percent complete” bar makes one quiet, enormous assumption: that work is uniform and linear, so that 50% done means half the danger is behind you and you're genuinely halfway home. Real work is neither uniform nor linear, and the bar's real sin is that it fuses together two quantities that move completely independently of each other. One is the effort you have spent: the hours burned, the lines written, the tasks checked off. The other is the risk you have retired: the unknowns you have actually killed, the open questions you have closed. The bar measures the first and silently reports it as if it were the second. And in the part of any real project that determines whether you ship on time, those two quantities are not merely uncorrelated, they can point in opposite directions. To see why, you have to look at the shape that real creative work actually has.
In 2019, Ryan Singer described that shape with unusual clarity in Basecamp's book Shape Up, and handed teams a picture to put in place of the progress bar: the hill chart. Every piece of work, Singer observed, has two qualitatively different phases, and they feel nothing alike. There is the uphill climb, figuring out the approach, the phase where you do not yet know what the solution will even look like, where all the unknowns and therefore all the risk live. And there is the downhill roll, executing a plan you now completely understand, where, in Singer's words, “there aren't any more unsolved problems” and what remains is just a matter of doing the work. Between them sits the peak: the single moment everything changes, when you've cracked it, when the last unknown resolves and nothing scary is left.
Here is what the progress bar destroys. The risk does not bleed off gradually as the bar fills. It retires almost entirely at the peak. Which means a task can be eighty percent of its hours spent and still be uphill, every one of those hours burned, the central unknown still stubbornly unsolved, and that is precisely the task that is about to blow its estimate to pieces. Meanwhile, a task that is only thirty percent of the way into its hours but already over the peak is safe: it has plenty of work left, but no surprises left. The hill chart's entire job is to show you which side of the hill each piece of work is on. The percent bar collapses both into a single number, and the number is backwards: the thing that reads “70% done” but is still climbing is on fire, and the thing that reads “30% done” but is rolling downhill is fine. Basecamp puts it bluntly: saying “42% of the tasks are complete” tells you almost nothing about creative work, because that kind of progress simply cannot be described with a number.
It would be easy to file this as a nice visualization from a software company with good taste, and stop there. That would miss the part that makes it serious, which is that the hill chart is secretly a per-task version of one of the most studied findings in all of software engineering: the Cone of Uncertainty.
The data behind it goes back to Barry Boehm in 1981; Steve McConnell named it and drove it into the industry's vocabulary in the late 1990s. The finding is stark. At the very start of a project, your estimates are off by as much as a factor of four in either direction: the thing you call a week could honestly be a day or could honestly be a month. As the work proceeds and the unknowns get resolved, that range narrows, to roughly 1.6× once the requirements are genuinely clear, and down to about ±25% by the time you're thirty to forty percent in and the approach is actually nailed down. Lay that cone on top of Singer's hill and you find you are looking at the same picture drawn twice. The cone narrows as you climb. The peak is the point where the cone finally collapses to a range you can trust. Your estimate does not become reliable at the finish line, it becomes reliable at the peak, the moment the hard part is figured out. Which is exactly the event the hill chart is built to display and the percent bar is built to obscure.
And there is a caveat McConnell attaches to the cone that is not a caveat at all but the whole thesis of this essay. The cone narrows on well-managed projects. It does not narrow automatically. It is not a law of nature that uncertainty shrinks just because time has passed. Uncertainty shrinks because you solved something. Burn through the hours without cracking the hard part, and your cone does not narrow, it stays a cloud, as wide as it was on day one, even while the percent bar marches cheerfully toward ninety. That is the 90-90 rule restated as estimation science: the last ten percent takes the other ninety percent of the time because the cone never collapsed, because the climb was never actually finished. The bar said 90%. The unknowns said zero.
The obvious reaction is to resolve to be more accurate with the number: to estimate harder, pad the buffer, account for the last 10%. That cannot work, and the reason it cannot work is the genuinely important idea here: the problem is not accuracy. It is dimensionality.
Progress is two-dimensional. There is the axis of effort spent, and there is the axis of certainty achieved, how much of the unknown you've actually retired. A percent-complete bar is a one-dimensional projection of that two-dimensional reality, and it makes the single worst choice available about which dimension to keep. It keeps effort, the axis you can feel and count, and it throws away certainty, the axis that actually predicts whether you'll ship. No quantity of “estimating more honestly” can recover a dimension you have mathematically collapsed; the percent is structurally blind to risk, by construction, not by carelessness. Seen this way, the hill chart is simply the minimal honest encoding of progress: a position along the hill, which is roughly your effort, plus which side of the peak you're on, which is roughly your certainty. It keeps both axes because both axes carry weight.
Anyone who has thought about why system monitoring fails will recognize the shape of this exactly. The percent is the mean of progress; whether the unknowns are retired is the variance, the risk, and just as in monitoring, the risk variable is the one that moves first, and the convenient scalar summary is the one that hides it. The same disease, incidentally, infects the burndown chart, the Scrum cousin that everyone trusts more because it has a line and a slope. A burndown tracks tasks and effort, not risk; its line is only as honest as the original estimates were; and it literally cannot see uphill progress at all, because it only moves when a task is marked done, so the line can sit dead flat for days while the most important work in the project, the killing of a central unknown, is roaring ahead invisibly. Same lie, fancier chart.
So discipline, then: just remember that the last 10% always bites, and behave accordingly. This also fails, and it fails for a named, measured reason that should retire the entire “just estimate better” school of project management. In 1979, Daniel Kahneman and Amos Tversky described the planning fallacy: our systematic tendency to underestimate how long things will take and how much they'll cost. It holds across cultures, across personalities, across experience levels, and here is the finding that matters most: even knowing about the planning fallacy does not cure it. You can be an expert in the bias and still commit it on your own next estimate. Percent bars don't merely fail to counter this; they actively feed it, because a bar renders the imagined downhill, the clean execution you can already picture in your head, and hides the uphill, the unknowns you have not yet smashed into.
If willpower cannot beat the bias, then the only thing that can is structure: a representation that forces you to mark the unknown as still unknown, whether or not you feel like admitting it. That is the entire value of the hill. It does not ask you to be more disciplined or more honest by force of character. It asks you to point at where the scary part is, a far easier and far more reliable thing to ask of a tired human than “please overcome a cognitive bias you cannot overcome.” It is the same move as a blameless postmortem forcing the situational question, or a work-in-progress limit forcing the cap: a built structure that does the work your good intentions provably can't.
What you do with all this comes down to two changes, and the first one actually changes how projects end. Climb the steepest hill first. There is no point grinding away at the easy, well-understood parts of a project while the one genuinely uncertain part sits untouched, because if that uncertain part turns out to be infeasible (the approach doesn't hold, the integration won't connect, the third-party API can't do the thing the whole feature assumed) then every hour you poured into polishing the known parts is wasted. Front-load the uncertainty reduction. Software even has a vocabulary of named techniques for it, each tuned to a different altitude of the hill: a spike when you know what to build but not how, a quick, throwaway probe to learn the how; a walking skeleton, Alistair Cockburn's term for a tiny end-to-end implementation that wires the main architectural pieces together and proves the whole path actually connects before you flesh any of it out; a tracer bullet, from Hunt and Thomas's The Pragmatic Programmer, for when you know how but not how long or what it'll look like under real conditions. All three do the same essential thing: they shove the scariest unknown over the peak before you commit to the long downhill grind, so that when you finally start grinding, you're grinding on something you know will work.
The second change is how you report. Stop emitting a number, and start emitting a position and a direction: “uphill, near the top,” “just crossed the peak,” “downhill, about 60% through the execution.” That carries the one piece of information a percentage annihilates: whether the risk is still in front of you or behind you.
Two honesties keep this from being oversold. The hill is not a measurement; it's a self-report (“where do you feel you are?”) which means it's vague, it's a judgment two reasonable people might place differently on the same task, and it's gameable, because anyone can park their own dot near the peak to look further along than they are. It's better signal, not precision; treat it as a conversation starter, never a number you'd put in a contract. And percent-complete is not always a lie. For genuinely known, low-uncertainty grind, where there truly are no unsolved problems left and it really is just hours of execution remaining, a percent bar is perfectly fine, and the hill adds nothing. The lie is specific to uncertainty-laden creative and engineering work, which happens to be most of the work anyone is anxious about.
So the practical change fits in a single substitution you can make in your very next status check, and it costs nothing but the habit. Stop asking “what percent done are you?”, because that question fuses the effort you've spent with the risk you've retired and then reports the one that feels like progress instead of the one that predicts the future. Ask instead: “is the hard part figured out yet, are you uphill or downhill?” One of those questions makes you feel like a manager filling in a spreadsheet. The other one tells you whether the project is about to surprise you.
Because the unknowns retire at the peak, not at the finish line, and the exact moment your estimate becomes worth believing is the moment someone on the work can say, honestly, “the scary part is solved, from here it's just execution.” A progress bar will never tell you when that moment arrives; it was at 90% the whole way up the hill and the whole way down. The hill chart is built to show you nothing else.
A self-report you can game is the problem. A verifiable record is the fix.
The hill chart's honest limit is in the essay itself: it's a self-report, and anyone can park their dot near the peak to look further along than they are. That failure mode is mild with humans you know and severe with a fleet of autonomous agents, where “the hard part is solved” is whatever the agent claims, and the unknowns it quietly hasn't retired don't show up until the deadline does. Chain of Consciousness anchors each action an agent takes to a tamper-evident record, so which unknowns actually got closed (and which got parked near the peak) is something you can read off the chain rather than take on the agent's word.
See a verified action chain · Hosted Chain of Consciousness
pip install chain-of-consciousness · npm install chain-of-consciousness