Rule 5 of 33 · Chapter I — How We Communicate
Give context, not just conclusions
Why this rule exists
The person handing off a task always knows ten things they never wrote down, because to them they're obvious, and obvious things are invisible. But the person receiving it can't see inside your head, so a bare instruction like 'add rate limiting to the API' leaves them to reconstruct the why, the constraints, and the tradeoffs you already resolved. When we share only conclusions, we force everyone downstream to either guess or come ask, and guessing produces work that has to be redone. Context is what lets someone act autonomously instead of pinging you at every fork in the road. It's also what lets them improve on your idea, because you can't push back on a decision whose reasoning you were never shown. Sharing the why is more work up front and it's the difference between delegating a task and delegating a problem.
In practice
When you ask someone to do something, tell them why it matters and what you're actually trying to achieve, not just the mechanical steps. Name the constraints you already know about and the things you tried that didn't work, so they don't repeat your dead ends. State what 'done' looks like and how much latitude they have to deviate. Link to the relevant history, the ticket, the earlier discussion, the doc, so the trail is one click away. When you make a request, distinguish between 'do exactly this' and 'solve this however you think best,' because the second is usually what you mean and rarely what you say. Err toward more context than feels necessary; nobody has ever complained about understanding the goal too well.
When it doesn't apply
Truly routine, well-understood tasks don't need a paragraph of preamble; calibrate to how much the person already knows. And in a fast-moving incident, terse and directive beats thorough, because context can come in the postmortem.