When Not to Use the Two-Minute Rule

Why does a five-minute job take three days?

Because you never do it once. You do a version of it every time it crosses your mind.

Write the ticket. Size it. Decide whose it is. Watch it sit. Get asked about it in a standup. Re-explain the context to whoever finally picks it up. Every one of those steps costs more than the change did, and not one of them moves it forward. The rule works by deleting the negotiation — there is nothing to route, so there is nothing to route it through.

The second cost is the reload. Right now you have the file open and you know why the line is wrong. On Thursday you will pay fifteen minutes to rebuild what today costs you nothing to keep.

Here is one from this week. A field on our own board got renamed. The fix was a two-minute edit to one default string. It waited — and while it waited, a job that runs every two minutes failed every single time it ran, for most of a day, without one error message anybody read. Two minutes of work, deferred, bought a day of a machine reporting nothing wrong while doing nothing at all. Failures that stay quiet are their own category of problem.

So when should you ignore it?

Three cases. The first two are well travelled and worth stating quickly.

When you are in flow. A two-minute detour out of deep work is never two minutes; it is two minutes plus the twenty it takes to get back. Write it down and keep going.

When "two minutes" is a guess. Most small tasks are small until you open them. If you have not done this exact thing before, you are not estimating — you are hoping.

The third one is the one nobody warns you about, and it is the only one that has ever cost me real money.

Is it quick, or is it quick and undoable?

Five minutes to send an email to eight thousand people is still an email to eight thousand people. Five minutes to drop a table is still a dropped table. Five minutes to push a pricing change is still live pricing.

Every published version of this rule optimises for your attention. None of them mention blast radius, because they were written for a desk and an inbox, not for a system with customers attached to it.

So the test has two halves, not one. Not "is this quick." Is this quick, and can I undo it? Speed is only free when the work is reversible. Anything that fails the second half goes back in the queue on purpose and gets the second pair of eyes it earned — not because it is big, but because being wrong about it is expensive.

What happens to the backlog?

It stops being a graveyard.

A backlog full of two-line fixes is not a plan. It is a pile of guilt with a search function, and nobody opens it, because opening it means scrolling past forty things you already feel bad about to reach the one that matters.

Clear the reversible small things as they appear and what survives is genuinely large. Every item left deserves the estimate you give it. The list gets short enough to read, which is the only property a backlog has ever needed.

What it changes

The question you ask at the end of a session.

It stops being "what did I add to the list today." It becomes "what is left that still needs a person to think about it." That list is shorter than you expect, and it is the only one worth planning.