Across the night
Handing Over Work That Is Actually Finished
Finished work is the cheapest thing that crosses a gap, provided the word finished means the same thing at both ends.
four things · four nights · one that no number of nights settles
Four states, and only the first costs nothing extra.
Six things described as finished when they were handed over, and what happened next
Reviewed and merged the next morning, which is the whole of the good case
Merged, but the reviewer asked afterwards what problem it had solved
Finished in every sense except the one that mattered, and it cost two further nights
Comments arrived in one pass because the ask was unambiguous
The other end read it, was unsure what was wanted, and asked
Finished as work, unfinished as a thing in the world
six things · nine nights
Six things, nine nights, and four of them avoidable. Every overrun came from the same gap: the sender knew what finished meant and had not written it down. One team's own week, logged by the person receiving.
A piece of work handed over complete costs one night and nothing else. It is the only transaction in this arrangement that has no hidden price.
The practical question behind Handing Over Work That Is Actually Finished is whether progress can be checked without interrupting the people doing the work. remote employee monitoring adds time and activity evidence to the written record, so the next conversation starts with context instead of guesswork.
Teams comparing established approaches can also review Slack's collaboration hub for a practical example from a widely used product ecosystem.
Which makes it worth being precise about what complete means, because most of the expensive handovers in a week are things somebody believed were complete.
The three senses of finished
Finished as work. The thing has been built, it does what it was meant to do, and the person who built it has nothing further to do with it.
Finished as a transaction. Somebody else now has everything they need to do the next thing without asking a question. This is a stronger condition and it is the one that matters across a gap.
Finished as a fact in the world. The change is deployed, the document is published, the client has been told. This is stronger again and is frequently assumed by whoever asked for the work.
Work can be finished in the first sense and incomplete in the other two, and the gap between those states is where nights go.
Making it finished as a transaction
Four things, and the list is short enough to be a habit rather than a checklist.
Say what it is. One line naming the problem it solves, not the change it makes. The change is visible; the problem is not.
Say what you want from the recipient. Review, approval, a decision, or nothing. "Nothing, for information" is a legitimate and underused answer, and saying it saves the recipient the time they would otherwise spend working out whether they owe a response.
Name the person, if the thing needs a specific one. Addressed to everybody means addressed to nobody, and on a team where the reply costs a night, a message that sits for a day while two people each assume the other has it is expensive.
Say when it stops mattering. If there is a deadline, give it. If there is not, say that too, because the absence of a stated deadline is routinely read as urgency.
- What it is, named by the problem it solves rather than the change it makes.
- What you want from the recipient — including "nothing, for information".
- Who specifically, if it needs a particular person.
- When it stops mattering, or that there is no deadline.
The approval nobody asked about
The most common way a finished thing turns out to be unfinished is that it needed sign-off from somebody the person doing it had not thought about.
This is worth catching before starting rather than at the end, because at the end it costs a minimum of two nights and often more — the question crosses, the person asked turns out not to be the right person, and a third crossing goes to whoever is.
The question to ask at the start is not "who approves this?" but "who would be annoyed to find this had happened without them?" That version produces better answers, because it reaches the people whose authority is real but undocumented.
Deploying, publishing, telling
Work that is finished and not yet in the world is a particular trap on a team with a gap, because the person who built it is asleep when somebody notices it has not landed.
The useful rule is that the person finishing the work either completes the last step or says explicitly that they have not and who is expected to. A note reading "merged but not deployed; happy for anybody to deploy it" takes eight seconds and removes an entire category of morning confusion.
What produces the confusion is silence, because silence after finished work reads as completion.
The case for saying less
Everything above argues for adding a few lines, and there is a limit worth naming.
A handover note attached to genuinely complete work should be two or three sentences. If it is longer, the work is probably not as finished as it is being described, and the extra length is the sound of somebody explaining the parts they were unsure about.
That is a useful signal to notice in yourself. A note that keeps growing is telling you to change the label from finished to in progress, which costs nothing and sets the right expectation at the other end.
Why this is the cheap case
Everything else in this section is about managing loss. This is the one transaction where there is none to manage.
It is therefore worth a disproportionate amount of attention: the best available improvement to a team's week is usually not better handling of half-finished work, but a larger share of the work being genuinely finished before it crosses at all.