The shape of the new estimate error
The first 80% of a feature now takes an hour. The last 20% takes the three weeks it always took.
That is the whole lesson, and everything else is a consequence. A working demo exists on day one: the screen renders, the happy path works, somebody can click through it. What remains is the part that was always the work: the empty state, the concurrent edit, the migration for existing rows, the permission rule, the failure of the service it depends on, the case where the customer has 4,000 of them, and integrating with the thing another team is halfway through changing.
So the estimate error changed shape. It used to be roughly proportional: a task estimated at two days took three. Now it is bimodal: a task looks finished on day one and completes on day fifteen, and the gap between those two dates is invisible from outside.
Why this damages more than a plain overrun
Stakeholders saw the demo. Once somebody has watched the feature work, “three more weeks” sounds like an excuse rather than a description. This is a communication problem created by the tooling and it needs handling before the demo, not after.
Your own judgement is affected too. You have seen the thing working. The remaining work is abstract and the completed work is vivid, and the ratio between them feels smaller than it is.
The remaining work is the hard work. Not merely the last fifth by volume: the fifth that requires understanding the system, deciding edge cases and integrating with reality. It is also the fifth that is slowest to verify.
Estimating anyway
Count the unknowns, not the code. The question is not how big the change is. It is how many things nobody has decided yet. Run the ambiguity audit; each unresolved item is a source of variance, and a task with nine of them is not a two-day task whatever its size.
Use reference classes, not intuition. Do not ask how long this will take. Ask how long the last five things that resembled it took. Your issue tracker holds this and almost nobody looks. Reference-class forecasting outperforms expert judgement consistently, and it is a database query.
Split until you can count. If a piece cannot be described in one sentence without “and”, split it. Keep splitting until every piece is something you have done a version of before. Then the reference class works.
Estimate to deployed, not to demo. Say so explicitly. “Two days to something you can look at, two weeks to something customers can use” is an honest sentence and it sets the expectation at the right moment.
Add the integration tail deliberately. Migration, flag, rollout, monitoring, the support team knowing, the old path deleted. This list is roughly constant per feature and it is what is missing from almost every estimate.
The sentence to use
When the demo goes well and somebody asks whether it is nearly done, the useful answer is specific rather than defensive:
The happy path works. Still to do: what happens when a customer has none of these, what happens when two people edit at once, the migration for the 40,000 existing rows, and the permission rule for agency accounts. That is about two weeks, mostly on the migration.
That answer is credible because it is enumerable. “It’s more complicated than it looks” is not, and it is what people say when they have not made the list.
The 90/90 rule, updated
Tom Cargill’s old joke (the first 90% of the code takes 90% of the time and the remaining 10% takes the other 90%) was funny because it was recognisable. It is now closer to arithmetic than to satire.
The underlying reason has not changed since he said it. Essential complexity is the part that resists, and the current wave removed accidental complexity faster than any previous one. The visible portion of the work shrank; the invisible portion did not; the ratio between them got worse.
Which means the honest planning move is to make the invisible portion visible early. Write the edge cases on the board on day one, before the demo, while nobody has yet seen the thing work and everybody’s expectations are still adjustable.
Every lesson here is open. Your progress is recorded once you pass the AI at Work exam.
Check your understanding
A team demos a feature on day two. The manager schedules the launch for the following week. The team says it needs three more weeks. Which practice would most reliably have prevented the disagreement?
Pick the one you would defend. Your answer stays private.
Stuck on something?Ask Larissa, your AI tutor