On this page
"Can you remind me why we decided this?"
It is a reasonable question. It can also be a sign that a project is charging interest on missing explanations. Somebody has to stop, recover the discussion, work out which parts still apply, and pass the answer along. Then the next person asks again.
I don't think the number of open tabs tells us much about that cost. An engineer can move between an editor, a browser, and a document without losing the plot. One carefully organized task board can still send them hunting for the reason behind every other item.
The useful thing to reduce is reconstruction.
A small example with an expensive ambiguity
Imagine a team building an export. The task is open, assigned, and scheduled. Its description says to export filtered results. The design shows an export button. Everything appears ready.
During implementation, someone asks whether exported files should contain private internal notes. The product lead remembers agreeing that they should not. The engineer who joined last month has never seen that conversation. A screenshot in the task predates the decision. The document describes an earlier version.
The problem isn't that nobody wrote anything down. There is plenty to read. The problem is that the reader cannot tell which explanation governs this piece of work now.
Adding another status field won't resolve that. A short sentence near the task might. "Export the current filtered result, excluding internal notes. This file is intended for customers." If a decision document explains the access rules, link it from there. Now the boundary and its reason travel together.
Write for the person who missed the meeting
I try to make the next useful note answer the question that would otherwise interrupt someone. That often means recording an exclusion or a tradeoff rather than narrating everything that happened.
"We discussed export" gives the reader almost nothing. "We kept internal notes out because the file will be shared externally" gives them something they can apply to the next edge case.
The second sentence is also easier to correct later. If the audience changes, the assumption is visible. A future engineer doesn't have to infer it from the implementation.
There is a limit. Copying an entire design document into every task makes each copy harder to maintain. The task needs enough context to understand the action and a clear route to the explanation. It rarely needs the whole project history.
Old information should look old
A document can be wrong in a subtle way. Most of it remains accurate, but the implementation changed one important detail. That makes it more dangerous than an obviously abandoned note.
When a decision changes, I prefer a small dated correction at the point where someone would otherwise act on the old information. Explain what changed and link the replacement. Deleting every trace of the previous reasoning can be unhelpful too. Sometimes the old approach was reasonable under a constraint that has since disappeared.
The aim is to let a reader distinguish a current instruction from useful history. They should not need to compare timestamps across five tools to work that out.
This is also why the release record matters. A decision can be correct for the current implementation while describing behavior customers haven't received yet. Connecting it to what shipped prevents a different kind of confusion.
Try this on one confusing task
You don't need to reorganize the company to improve the next handoff. Pick a task that recently caused a clarification. Read it as somebody who wasn't in the discussion. Find the first question you cannot answer from the task or its links.
Then add the smallest explanation that would have prevented that question. It might be the reason for a deadline, the dependency blocking the work, or the behavior deliberately excluded from this release.
After the next change, check whether the explanation survived. That is a better test than whether the document looks complete on the day you write it.
I use this test when building Bisonflow. Documents and tasks belong near each other because people need to move between action and explanation. Putting them in one app helps with distance. It doesn't automatically make either clear. The words still need to carry the decision.
My favorite result is a boring one. Someone returns to the work, reads what they need, and carries on without asking me where the answer lives.
