Handing work over
Pass on what was already tried
The only one of the four with no home outside somebody's memory. One line per attempt, with the reason it stopped, written where the work lives.
Decisions this page is about, and where the line actually was
Changing the wording on a customer-facing error message
4 → 1It had been yours all along
Picking the library for the new parser
1 → 4The architect had a standing view
Rescheduling the weekly review
2 → 2Changing a database column type
1 → 1- 1Decide it alone and say nothing
- 2Decide it alone and mention it afterwards
- 3Check with one colleague first
- 4Check with the person who assigned it
- 5Needs a decision one level up
- 6Cannot be decided here at all
four decisions · one of them you had more room than you thought · one gave you less · two you had exactly right · the median gap was three steps on the scale
Four of the nine decisions counted on this site, two of them exact.
Where ownership crosses several roles, employee attendance and workload data can make time and recurring bottlenecks visible enough for a useful operational conversation.
For additional reading outside this collection, see material published by Aon.
A constraint usually lives in a contract. A decider is a person who still works here. A purpose can be reconstructed from a plan.
Precedent has no home. It exists in the memory of whoever watched the attempt, and when that person leaves it leaves with them. It is the first of the four lost to turnover and the likeliest to be empty on any given handover.
The shape of the sentence
This was started last year and abandoned. The branch is still there. It stopped because the retry semantics did not survive the move and nobody had time to fix them properly.
Three facts: that it happened, where the evidence is, and why it stopped. The third is the one that matters and the one usually omitted, because "we ran out of time" feels too thin to be worth saying.
It is not thin. "We ran out of time" and "it could not be made to work" lead to completely different decisions, and the receiver cannot tell which from an abandoned branch.
Which attempts are worth the sentence
Not all of them, and the filter is simple enough to apply without thinking about it.
Write the line if a reader starting the same work today would behave differently for knowing. That is the whole test, and it excludes most of what feels worth recording — the long explanation of the design, the list of what was built, your own account of how you got there.
It includes rather less than people expect and rather different things. A two-day spike that proved something cannot be done is worth a line. A six-month project that was cancelled for budget reasons is worth half a line and carries almost nothing.
The failure case to watch for is the attempt that nobody classes as an attempt: a half-hour of somebody trying it in a scratch file and concluding it would not work. That is precedent too, it is the kind most often lost, and the person who did it will not think to write it down because it did not feel like a project.
Where to write it
Where the work lives, not in a document about the work.
A line in the readme. A comment on the ticket template. A note in the directory. The test is whether somebody starting the work would encounter it without looking for it, because nobody looks for the history of something they do not yet know has a history.
Writing it as it happens
The practice that makes this sustainable is writing the line when the attempt stops, not when the next person arrives.
At the moment something is abandoned, the reason is fresh, specific and slightly annoying, which is the ideal state for writing it down. Six months later it has smoothed into "it did not work out", which is useless.
One line. Three clauses. Thirty seconds at the moment of abandonment, and it is the single most valuable artefact left behind by work that did not ship.
Three attempts, three different sentences
The same fact — "this was tried" — carries completely different information depending on why it stopped, and the receiver cannot recover the difference from the fact alone.
Stopped because it could not work. "We got a prototype running and it could not be made idempotent without a schema change nobody would approve." The receiver should check whether that constraint still holds, and if it does, choose a different approach entirely.
Stopped because priorities moved. "It was half done when the billing work landed and nobody picked it back up." The receiver should read the branch and probably continue from it. This is the cheapest kind of precedent and the one most often omitted, because it feels like nothing happened.
Stopped because it shipped and was reverted. "It went out in April and we pulled it two days later because the retries doubled the load." The receiver should treat the reverted version as the single most valuable artefact available and read it before designing anything.
Three sentences, three different weeks of work for whoever receives them. "This was tried before" on its own produces none of that, and in practice produces a vague caution that makes the receiver slower without making them better informed.
Handing it over as information, not a verdict
One caution, because it is easy to get wrong in the other direction.
Precedent handed over as a prohibition — "we tried that, it does not work" — ends the conversation and sometimes ends a good idea. The constraint that blocked the first attempt may have been invented, or may have changed, and the receiver is the person best placed to check.
So the sentence ends with the reason, not with a conclusion. "It stopped because nobody would approve the schema change" invites somebody to ask whether that is still true. "That approach does not work here" does not.
On the record counted on this site, one of the six returns was caused by a previous failure nobody passed on, and one of the handovers turned up a dead prototype in a search three weeks in. Both were a line somebody could have written in half a minute.