The One-Day Rule Isn't About Time
"I literally don't care what it is. I don't care if it's building an airplane. Why would you start with anything longer than that?"
That is Taylor Otwell, arguing this week that when you estimate any new project, your default should be to assume it can be done in one day until proven otherwise. The tweet lit up my feed, and the replies were better than the tweet.
The literal reading is easy to dunk on. No, you are not shipping a 737 by Friday, and half the replies said exactly that. But the literal reading misses what the rule actually does. Once I sat with it, I realized it transfers straight into operations and process design, where it might matter more than it does in engineering.
#It's a decomposition trigger wearing an estimation costume
A normal estimate flows one direction. Look at the work, guess a number, pad the number because you have been burned before. "Two weeks." That figure hides all of its assumptions inside one round guess. Nobody can see what you were afraid of.
Flip the question. Instead of "how long will this take," ask "why can't this ship today." Now every extra day has to earn its place out loud. This dependency. That review cycle. This unknown you have not resolved yet. The one-day prior does not make the airplane take a day. It forces you to name the specific thing standing between you and a day.
The airplane line is the tell. Even there, "what is the smallest thing I could finish today" has an answer. A subsystem decision. A spec. A mock. The rule is really "find the one-day version first, then argue about the rest."
#Where it breaks in engineering
Taken literally it falls apart, and you should know exactly where.
Estimates are promises other people plan around. Optimizing your own framing at the cost of everyone downstream is not a trade you get to make on your own.
Some latency is not yours to compress. External approvals. Hardware lead times. A two-week vendor turnaround does not shrink because you decomposed the work beautifully.
And the rule is survivorship-biased toward solo software work. One builder, a fast deploy path, a Kanban board, and it sings. Put it across a team with review queues and cross-service dependencies, and a naive one-day prior becomes the thing that is always wrong in retro.
So keep it as the opening question, never the closing answer. "What could I finish today" is a slicing prompt. "This whole thing is a day" is how you miss dates.
#The part that actually changed how I think: operations
Same mechanism, different unit. In estimation the prior is one day. In process design the equivalent prior is this: the step should not exist, and the work should be one pass with zero wait, until proven otherwise. You put the burden of proof on every gate, handoff, and queue instead of on the work.
The payload lands harder in ops, and the reason is a number most people have never measured. Flow efficiency, which is touch time divided by total lead time, sits in the single digits for most real processes. Often under fifteen percent. So when you ask "why isn't this done today," the answer almost never indicts the work. It indicts the waiting. Approvals sitting in a queue. Batch windows. Handoff boundaries where the item just sits and cools off.
Three concrete translations.
Approval gates. Default assumption: delete it, replace it with an after-the-fact audit. A pre-approval gate has to justify itself against a specific irreversibility or a real cost of error. Most gates are comfort, not control. The test is simple. What irreversible thing happens if this runs without the gate?
Handoffs. Each one is a queue plus a context-reload tax. Default: collapse it. Make the boundary prove why a different owner needs to touch the work, instead of one person carrying it through.
Batching. "We run this weekly" imposes up to a week of wait on the first item in the batch. That wait has to justify itself against the setup cost you are amortizing. Sometimes it wins. Usually it does not.
#Two guardrails, both non-negotiable
Theory of Constraints. The "why not instant" prior only pays at the bottleneck. Drive a non-constraint step to zero wait and you have accomplished nothing except piling inventory in front of the real constraint faster. Use the heuristic to find the constraint. Then optimize only there.
Design target versus published number. Same split as engineering. Your optimistic prior is a design target. It is not the SLA you hand to whoever depends on you. Little's Law, where WIP equals throughput times cycle time, gives you the honest external number from actual data. The gut prior does not.
#The stronger version
For process work, the best version of this idea is not even a time prior. It is a value-stream map with wait time drawn explicitly on every segment, then the same relentless question asked one segment at a time: why not zero wait here. It surfaces the same blockers the one-day question does. It just makes the queues visible instead of burying them inside a single duration guess.
Otwell's framing works as a hook because it is deliberately extreme. The airplane is the point. If the rule survives an airplane, it survives your sprint and your intake process. Start from the smallest shippable thing. Make every delay defend itself. You will find that most of your timeline was never the work at all. It was the waiting nobody was allowed to question.