A reviewer has two plausible implementations in front of them, and the CTO's request to ship faster doesn't tell them which behavior the product needs. That uncertainty can survive a passing test suite.
Take a hypothetical duplicate account update. One implementation ignores it, another rejects it, and both can have tests that match their own assumptions. The review needs the intended behavior and its decision owner before another code change is useful.
TeamStation's context-loss article proposes a five-field method for preserving that decision, explaining what belongs beside a change and why clarification should be separated from implementation defects:
https://teamstation.dev/research/articles/context-loss-rework-distributed-engineering
Put the decision where review happens
For distributed engineering, context needs to travel with the work. A ticket can carry purpose, the chosen behavior and its owner, constraints, supporting evidence, and the next action. Those fields are prompts for a useful conversation, not a requirement to write another large document.
The receiving engineer should check that the information answers their actual question. A field labeled "decision" isn't enough if it links to a thread they cannot access. An old answer also needs an update when the requirement changes.
Classify the return before counting it
When a change comes back, record the reason. Was the implementation incorrect, the expected behavior unclear, the evidence unavailable, or the scope newly changed? Combining those events makes engineering telemetry harder to interpret.
Start with a small set of comparable changes and examine the clarification involved. Keep that examination separate from individual performance ratings. Complex or unfamiliar work can need discussion even when the original handoff was sound.
The related smallest useful engineering signal connects a condition to its owner, context, and next decision. The access friction analysis addresses a different cause: the receiver lacks the access needed to continue.
Use the proposed check to find one repeated missing answer. Keep its owner and current evidence beside the change, then see whether the same clarification comes back. That gives the next review something concrete to test without claiming a measured productivity gain.
DistributedEngineering #EngineeringTelemetry #SoftwareDelivery
Related TeamStation sources:
GitHub topic map:
Source asset:
https://teamstation.dev/research/articles/context-loss-rework-distributed-engineering
Top comments (0)