Write for someone outside the conversation.
A decision brief often outlives the meeting that produced it. The next reader may not know which option was rejected, what a source identifier means, or whether a proposed action was approved.
Start with the decision requested and the current status. Then give enough problem context to understand the trade-off. Avoid making the reader reconstruct the recommendation from a chronological collection of notes.
Make the argument easy to inspect.
Place the strongest relevant evidence beside the claim it supports. State the audience and task, then explain why the team thinks the problem matters now. Keep assumptions about effort or impact separate from observed information.
A useful brief also gives the best alternative interpretation a fair hearing. This reduces the risk that a polished document simply makes an early opinion harder to challenge.
- Decision requested and current status.
- Problem context and source references.
- Alternative explanations and limitations.
- Proposed next step, owner, and review condition.
Record the outcome in the same place.
After the review, add the actual decision and its reason. A reader should not have to search a chat history to discover that the recommendation changed.
If the team defers the work, state why and when it would be worth reconsidering. A clear deferral is more useful than a brief that appears permanently “in progress.”
A brief is complete when a new reader can understand both the recommendation and what the team actually decided.
Edit for the next useful question.
Remove background that does not help assess the decision. Keep details that explain scope, limitations, and trade-offs. Concision comes from choosing the right information, not compressing every sentence.
Ask a colleague what question they would raise first. If the answer is basic context that the brief omitted, add it. If it challenges the reasoning, the document is helping the review do its job.