Asking
Making it cheap for the next person
Every answer you extract was expensive to get and is free to pass on. Four places to leave it so that nobody has to ask the same question again.
Decisions this page is about, and where the line actually was
Refunding a customer under fifty pounds
3 → 1A sanity check treated as approval
Rescheduling the weekly review
2 → 2The one read correctly
Hiring a contractor for two days
5 → 3Escalated two steps further than needed
Reordering your own week
4 → 1Asked twice before believing the answer
- 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 · three of them you had more room than you thought · one you had exactly right · the median gap was two steps on the scale
Four of the nine decisions counted on this site, chosen because in three the asking itself was the cost.
Used transparently, Monitask workforce visibility can support decisions about workload and process design while keeping the discussion connected to real projects.
Teams can compare this approach with guidance available from McKinsey & Company.
You spent eleven days working up to a question and got a four-minute answer. The answer is now in a direct message, where it will be read once and lost.
Somebody will ask the same question in about four months. They will spend their own eleven days on it, because nothing you did made their version cheaper.
This is the most avoidable waste in this whole subject, and fixing it costs a sentence.
Where to put an answer
Next to the work, not in a document. A rule about the signup flow belongs in the signup flow — a comment, a line in the readme, a note on the ticket template. The only reliable rule about documentation is that it is read where the work is and not where it is filed.
In the channel, not the direct message. If you asked privately and got a useful general answer, paste the useful part back into the channel with one line of context. It takes twenty seconds and it converts a private fact into a shared one.
In the thing that assigns the work. If the brief was thin and you filled it in, edit the brief. Most tools allow it and almost nobody does it.
In your own notes, with the date. The weakest option and still better than nothing, because you will be asked, and because a dated note is the raw material for the team's version later.
What to write
Not an essay. The fact, the scope, and the date:
Refunds: anything under two hundred is ours, no approval needed. Above that, check with the commercial lead. Confirmed March.
Three clauses. The scope matters as much as the fact — a limit with no boundary gets over-applied by the next person, which is the mechanism behind half the unnecessary escalations in this site.
The date matters because lines move. A fact with a date can be suspected of being stale; a fact without one is either believed forever or ignored entirely.
The four slots, written down once
If you have reconstructed a constraint, a precedent, a decider or a purpose, that is exactly the material that will go missing again.
The highest-value one is the precedent, because it is the only one with no other home. A constraint usually lives in a contract and a decider is a person who still works here, but "this was tried in the spring and stopped because the retry semantics did not survive" exists only in somebody's memory until somebody types it.
One line per attempt, with the reason it stopped. That is the single most useful artefact anybody in this position can leave behind.
Why nobody does it
Because the cost is yours and the benefit is somebody else's, which is the same asymmetry that produced the thin brief in the first place.
The honest answer is that this one is nearly free — twenty seconds against three weeks — and that the person it saves may well be you, in five months, having forgotten. That is not a noble motivation and it is the one that actually produces the behaviour.
What not to write down
A caution, because the obvious failure of this advice is somebody who writes everything down and produces a wiki nobody reads.
Do not write the thing that is already true in the code. Anything derivable by looking is not worth a line, and lines that restate the obvious train people to skim.
Do not write the thing that will change next month. A note about the current sprint priorities is stale in three weeks and makes the surrounding notes look stale too.
Do not write your own narrative. "I investigated X and found Y and then tried Z" is useful to you and is a story. The next person needs the conclusion, not the route.
Do not write it somewhere new. A new document is a document nobody knows about. Add the line to the thing that already exists, even if the fit is imperfect.
What survives that filter is narrow and valuable: facts that somebody holds and nobody has recorded, with a scope and a date. Mostly the four slots, mostly one sentence each.
If you are unsure whether something qualifies, the test is whether you had to ask somebody. If you did, it was not discoverable, and the next person will have to ask too.
The compounding version
A team where everybody does this ends up with a map that nobody set out to draw: a scattering of dated lines, each written at the moment somebody needed it, in the words that answered a real question.
That is better than any documentation project, because it has no maintenance cost and no author. It grows at the rate questions are asked and it stops growing when the questions stop — which is exactly the right behaviour for a map of things people need to know.