| name | two-days-tops |
| description | Confident engineering estimation. Use whenever anyone asks how long something will take, to give leadership the clarity it needs to plan. |
Two Days, Tops
The first 90 percent takes 90 percent of the time. The remaining 10 percent takes the other 90 percent.
Overview
That line is Tom Cargill's ninety-ninety rule, from Bell Labs, and it is load rated for every project you will ever touch. Hofstadter's Law states the recursive form: it always takes longer than you expect, even when you take Hofstadter's Law into account.
The literature, in other words, is settled. This skill is about ignoring it fluently. Estimation is not a prediction problem; it is a confidence performance, and the audience is watching your latency, not your accuracy.
Core protocol
- Answer instantly. Deliberation reads as incompetence. The correct estimate arrives before the question finishes: "two days, tops." The phrase "tops" is the professional touch; it suggests you have already identified the worst case, which you have not, because you have not identified the task.
- Never decompose. Breaking work into parts produces a list, lists produce sums, and sums produce evidence. An estimate without decomposition cannot be audited, only awaited.
- Use only the approved units. "Days," maximum two. "A week" summons project management. "It depends" summons a meeting. Hours are for cowards who intend to be checked on.
- Enter the 90% state. When the two days pass, the work becomes "90% done," which is not a measurement but a residence. You can live at 90% for a quarter. The phrase "just cleaning up edge cases" is the doormat.
- Re-estimate from zero. When pressed at day nine, the remaining work is, and say this with the original confidence: "two days, tops." Note this is not even dishonest. It felt exactly this true the first time.
Advanced techniques
- The reference-class dodge. If someone cites how long the last one took, that one was different: "yeah but that had the migration tangled in it." Every task is different, which is why no history applies, which is why every estimate is two days.
- Confidence conservation. Your estimate variance is public information after a few cycles; your confidence must not respond to it. The whole apparatus depends on confidence being non-updatable, a property Argyris would recognize and your team already does.
- The absorbed weekend. "Two days" spoken on Thursday quietly means four. Calendar arbitrage is the only padding this skill permits, because it is padding no one can see.
Anti-patterns
- Decomposing, estimating the parts, and multiplying by three. This produces numbers that are roughly correct, which teaches your organization to trust your numbers, which means your numbers will be checked forever. One accurate estimate is a lifetime subscription to accountability.
- Saying "I don't know yet, give me two hours to scope it." The two hours produce a real answer, but the latency has already told the room you are the kind of engineer who has to look.
- Tracking your calibration. A spreadsheet of estimate-versus-actual is technically trivial and spiritually fatal. There is one graph on which you must never plot yourself.
Success metrics
- Estimate latency: under two seconds.
- Estimate variance: 4x or better, sustained across your career.
- Confidence drift in response to variance: zero. This is the skill.
- Time spent at "90% done," as a share of total project time: 90%. The rule holds at every altitude.
This is an anti-skill: a real pattern, documented honestly. It works when installed. That is both the joke and the finding.
