How to delegate in writing: outcomes, not steps

Delegating in writing means handing over an outcome instead of a procedure. Put down what done looks like, what must stay true, and when you will look at it. The route belongs to the person doing the work.

Most written handoffs go the other way. They arrive as a numbered list of moves, which feels like care and behaves like a cage.

Why step lists come back wrong

A step list tells someone what to do and nothing about what you wanted, so it stops being useful at the first surprise.

There is always a surprise. The file is named something else. The customer already replied before anyone reached step four.

Now the person holding your list picks between two bad moves. They can follow instructions that no longer fit, which produces work you have to redo. Or they can stop and ask you, which produces a message in your inbox, which is the exact thing delegating was supposed to prevent.

The quiet cost is the worse one. Someone working from steps cannot tell you your plan is wrong, because you never showed them the plan. You showed them the output of your thinking, chopped into instructions, and the thinking was the part you wanted help with.

I write specs for pieces of Unvent, and the good ones open with what a person should be able to do by the end. The bad ones open with a list of files to change, and the moment one of those files turns out to be the wrong place, the list is dead weight and the real work starts from an empty page anyway.

What an outcome sounds like on the page

An outcome is a sentence describing the world once the work is finished, written so someone else can check it without asking you.

"Update the onboarding doc" is not that. "A new person can set up their laptop from the doc without messaging anyone" is. The second version can be tested by somebody who has never met you, which is the whole point.

A handoff that works usually carries four things:

• The finished state, written so the other person can tell whether it is true yet.
• Who the work is for, because the audience settles half the small choices without you.
• Why it is happening now, in one sentence, so tradeoffs fall the right way when something has to give.
• What good enough means, because most work has a ceiling nobody ever says out loud.

That last one saves the most time. People overbuild when nobody told them where the finish line sits, then feel bad about the days they spent on a part you never cared about. Write the ceiling down. In my experience people are relieved by it far more often than they are insulted.

Name the constraints and stop there

Constraints are the facts that must stay true however the work gets done, and they are the only piece of the how worth writing down.

The test is easy. If someone breaking the rule would make you unhappy, it is a constraint. If it would only make you feel unfamiliar, it is your habit, and you were about to make your habit somebody else's job.

• The date, and whether it is a real date or a preference dressed as one.
• Anything they must not touch, with one clause saying why.
• What has already been tried, so nobody spends a day rediscovering it.
• Who they can talk to without checking with you first.
• What to do when they get stuck, including how long to sit with it before saying so.

Written honestly, that list is short. Most of what gets called requirements is preference with a serious face on.

Say which decisions are theirs

Name the decisions the other person owns, because decision rights you leave unstated come back to you as questions.

Anything you did not hand over stays yours by default, and everyone knows it. So they ask. And each ask arrives in your day at the moment they hit it rather than a moment you chose, which is how a delegated task turns into a slow drip of interruptions with your name on both ends.

Two lines usually cover it. "Wording and structure are yours." "Anything that moves the date comes back to me." Now the work can move without you in the room.

The reverse is worth learning too. When you are the one holding the task and something genuinely needs the other person, ask for the decision directly instead of describing the situation and hoping a verdict appears.

Put one checkpoint well before the deadline

Set a checkpoint at roughly a third of the way in, and say what you want to see at it.

A checkpoint at the end is a delivery. By then your choices are accepting it or spending whatever time is left fixing it.

Early checkpoints feel like distrust when they arrive as "how's it going". They land differently when they name a thing: an outline, a rough draft, the first screen, the list of questions found so far. Ask for something you can open and read.

For anything running longer than a couple of weeks, a light regular update beats one big review. A short written update saying what moved and what is stuck does the job.

Handoffs read colder than you mean them

A written handoff sounds harsher than the same words spoken, for the same reason a short Slack message reads angrier than you meant it: the reader has to supply a voice for it, and a busy reader supplies an unfriendly one.

Briefs get hit hardest because a brief is already a list of instructions. My first drafts do this constantly. I write what looks like a clean spec, read it back an hour later, and find a work order from a stranger who does not like me much. The repair is small. One line saying why the work matters, one line saying what to do when it goes sideways.

That gap between what I meant and what I typed is the reason Unvent exists at all. Taking the Warm rewrite closes that gap, and the stranger who does not like me much stops signing my briefs.

When steps are the right thing to write

Write steps when the method itself is the requirement.

• The procedure is the point, as with anything carrying legal or safety wording.
• One wrong move destroys something you cannot get back.
• Someone is using a tool for the first time and needs a path through it once.
• The task is a one-off, and explaining the reasoning costs more than doing it yourself would.

Outside those, steps are usually about you. I think most step-by-step handoffs exist to avoid a harder sentence, which is saying plainly what you care about and then living with somebody else's route to it.

When the work comes back wrong

Check your brief before you check the person.

Half the time the gap is in the handoff: a constraint you never said, a ceiling you assumed, an audience that only existed in your head. That is cheap to fix, and worth admitting out loud rather than saying "no worries" and quietly redoing the thing at eleven at night.

When the miss really is in the work, name it early and name it against the brief. Say what is missing and which line of the brief it was meant to satisfy, so the conversation stays about a document instead of a character flaw. The wording of those notes is a separate job.

Then rewrite the brief anyway, while the miss is fresh and you can still see which sentence caused it. I am bad at this part. The work is late by then, the fix is obvious to me in that moment, and going back to edit a document nobody is waiting for feels like the least urgent thing available, so I close the tab and about a month later I write the same vague brief again.