The reply in your queue is not a start

You did not put “rewrite Sam’s almost-ready follow-up” on Tuesday. It still took the first hour. Then the ticket that was marked done with no customer reply. Then the quote that used last month’s price because nobody read it before it left someone else’s screen.

That is not a slow week. That is a handoff with no owner.

Half-done replies. Tickets that sound close. Follow-ups that almost match your voice. They generated. You inherited. The generator already got their time back. You did not, and customers wait while you fix work that looked finished from the other desk. Lenny Rachitsky (@lennysan), who spends his week asking product people what is actually happening in their jobs, found this near the top of the pile: teammates dump drafts that you then have to clean.

So here is the rule, and it is one sentence. Don't inherit the draft. If nobody reviewed it before it left their screen, it is not a start. It is a mess with a timestamp. You can refuse it. You can send it back. What you should not do is quietly become the cleanup department.

The dump is a bill

A dumped draft costs twice. Once when it was generated. Again when you sit with it. You already pay for the person or the tool that produced it. Then you pay again for the person who has to make it true: the right amount, the right tone, the right promise. That second payment does not show up as a line item. It shows up as a morning that vanished.

Treat an unreviewed draft the way you treat an unsigned check. It can sit in the pile. It does not go out under your name.

Send it back with one sentence: “Read this before it hits my queue.” That sentence is the whole policy. You do not need a new stack. You need a boundary.

Let the broken path finish

Cleanup also hides in the sequence you killed. A follow-up sequence starts going out wrong, someone pulls the plug in the first minute, and everyone treats that as the responsible move.

It costs you the only useful thing about the failure. You never learn whether it would have billed the wrong amount, CC’d the wrong owner, or sent the same apology three times. You see the first ugly message and guess at the rest, then change the process based on the guess. Logan Kilpatrick (@OfficialLoganK), who works on AI developer tools at Google, made the uncomfortable version of this point: stopping a bad run halfway hides how far the error actually goes.

This week, when a sequence is already in motion and it is wrong, let one of them finish in a sandbox you control. Your own test thread. A dummy customer record. A folder nobody else can send from. Watch every step. Write down every bad send. Then change the rule.

You are not being reckless. You are refusing to fix a leak you have not measured. The full mess is information. A half-stopped mess is a story you tell yourself.

Figure 1

Draft leaves their screen

Decision: Did a person read it first?

One of these

YesYou can send or tweak

NoRefuse it. It is cleanup debt.

Decision: Bad sequence already running?

One of these

Stop halfwayYou never see the blast radius

Let one finish in a test threadYou see every bad send

Fix the rule. Then send for real.

The green path is the only one that returns hours. The purple path is how Tuesday disappears.

Closed is not the same as done

Do not close a customer thread because a tool said it was done. Do not mark a quote sent because a draft exists. Open the thread. Look at what the customer can see. If you cannot point at the before and the after, it is still open.

Hiten Shah (@hnshah) was talking about coding agents when he set that bar — attach the before and after screenshots, do not just report “done” — but it travels to any handoff where the person reporting is not the person checking.

This is not ceremony. It is how you stop the second cleanup: the one that arrives as an angry reply two days later, after someone already celebrated the close.

A useful house rule: the person who clicks send is the person who can show what changed. If they cannot, they do not click send. The draft stays in their queue, not yours.

Last week’s pattern is not this invoice

Some of the cleanup is not laziness. It is a new problem wearing an old template. A lease with an odd clause. An invoice that does not match last week’s pattern. A ticket that is actually two tickets. Those still need a person who can reframe the work, and a canned reply will look finished while being wrong.

François Chollet (@fchollet), who has spent years on the gap between a trained model and a thinking one, puts it without romance: intelligence is making sense of a new problem on the fly, not already being competent at every case.

When the case does not match, do not polish the draft. Set it down. Name what is different in one line. Then write from that line. Polishing a mismatch is how you send a confident error.

There is a brake on the polishing too. Add another pass only when the last one actually made the thing better. If the second rewrite did not fix the amount, the date, or the promise, stop rewriting — change the facts in front of you, or hand it to the person who has them. Rohan Paul (@rohanpaul_ai) covered the research version: a team kept the improver fixed, fed each new layer the traces below it, and only went deeper while performance was still climbing.

Endless polish is also cleanup. It just looks like diligence.

Long jobs need a written state

Chat history is not a file. A lease renewal, an invoice trail, or an open ticket that spans months will drift unless someone keeps a written state: what was promised, what was paid, what is still open, who owns the next step. @dair_ai covered a study that ran an agent through a twenty-year simulated job and watched its memory come apart — which is the same failure, minus the excuse that a person was busy.

You already know this from the jobs that come back in month four with three different “latest” numbers. The fix is boring. A short note on the record. Dates. Amounts. The last thing the customer heard. Not a novel. A state.

If the written state does not exist, the next draft is a guess. Do not inherit a guess.

What to count this week

There is no honest industry number for what this costs you. Count your own shop.

For five days, keep a scratch tally next to the inbox. Three columns only.

At the end of the week you will have hours, not a story. If dumps are the bulk, the fix is the send-back sentence. If false closes are the bulk, the fix is before-and-after before anyone can mark done. If useless second passes are the bulk, one review with the facts in hand beats three polite rewrites.

The leak shows up as hours per person per week, not as a line on a dashboard, and that is enough to act on. Hours back on follow-up. Fewer wrong amounts. Fewer “wait, I thought that went out” threads.

You will not get a miracle week. You will get a queue that belongs to the people who send.

Put the rule where the send happens

Do not write a playbook. Write one line where people already work.

• Nothing leaves under your name unless you read it.
• Nothing gets closed unless you can show what the customer sees now that they did not see before.
• Unreviewed drafts go back.
• Broken sequences get one full run in a test thread before you change the process.
• New cases get named, not polished.
• Long jobs get a written state.

That is the whole week. It is already in the work. You are just refusing to pay for it twice.

Run the three-column tally until Friday. Then keep the one rule that cut the hours.