Written operating culture fails when every problem gets the same document. A company discovers memos, decides writing is good, and suddenly every issue receives a long narrative. That is not discipline. It is artifact confusion.
Different work needs different written forms. A decision memo helps choose among options. An update maintains shared context. An FAQ scales a decision or policy after it is made. An architecture decision record preserves a technical choice. A strategy note clarifies direction. An escalation brief helps leaders act under pressure. A postmortem turns a failure into learning. These artifacts are related, but they do different jobs.
The first question is the job of the document. Are we deciding, informing, aligning, escalating, recording, teaching, or learning? If the job is unclear, the artifact will sprawl. People will comment on the wrong thing because they do not know whether they are being asked to approve, understand, improve, or execute.
A decision memo is useful when the company must choose. It should frame the decision, options, evidence, owner, and next steps. If no choice is being requested, do not call it a decision memo. That only trains people to ignore the format.
An update is useful when the choice has already been made or when the main need is shared context. Good updates say what changed, why it matters, what is on track, what is at risk, what help is needed, and what happens next. They should not pretend to be neutral if they are actually asking for a decision.
An FAQ is useful after ambiguity starts repeating. If many teams ask the same questions about a policy, launch, reorg, pricing change, customer promise, or strategic shift, the company needs a reusable answer surface. A good FAQ is not a dumping ground. It is a way to reduce repeated interpretation work.
An ADR or decision record is useful when the decision will matter later. Technical architecture is the obvious example, but the same logic applies to pricing, segmentation, vendor choices, workflow design, and operating policy. The artifact should preserve why the choice was made and what alternatives were rejected.
An escalation brief is useful when time matters and leadership action is needed. It should not read like a full strategy memo. It should say what happened, what decision or intervention is needed, what options exist, what risk is live, who owns action, and by when. In escalation, the artifact should reduce time to action.
A postmortem is useful after reality has answered the memo. It should compare expected outcomes with actual outcomes, identify what the company misunderstood, and decide what changes. A postmortem that only narrates events misses the opportunity to update the operating system.
Choosing the right artifact also prevents document bloat. A one-page decision memo may be enough for a reversible product choice. A five-page memo may be appropriate for a major market bet. A short FAQ may solve a change-management problem better than a polished narrative. The format should fit the consequence and audience.
Written culture needs escalation paths between artifacts. A recurring update may reveal a decision that needs a memo. A memo may produce an FAQ after the decision. An ADR may later need a postmortem if the architecture creates unexpected cost. The written layer is a system, not a folder of unrelated documents.
Artifact choice also affects power. A memo invites debate before a decision. An update can close debate after a decision. An FAQ standardizes interpretation. A decision log preserves authority. Leaders should be honest about what the artifact is doing socially, not just informationally.
AI can help route artifacts. Given a messy set of notes, it can suggest whether the work needs a memo, FAQ, update, brief, or decision record. It can draft a first version in the right format. But the human owner still needs to decide the real job of the artifact. If that job is wrong, AI will simply produce the wrong document faster.
A practical written operating culture has a small artifact taxonomy. It defines the common document types, when to use them, what questions each must answer, and what "done" means. This does not have to be elaborate. The point is to stop reinventing the container every time important work appears.
The best test is reader behavior. Does the reader know what they are supposed to do after reading? Decide, comment, execute, escalate, remember, or learn? If the artifact does not make that clear, it has failed no matter how well it is written.
Consider a pricing migration. Before the decision, the company may need a decision memo comparing grandfathering, forced migration, and phased migration. After the decision, it may need an FAQ for sales and support. During rollout, it may need weekly updates on customer risk. After the rollout, it may need a postmortem on churn, expansion, discounting, and support load. One business change creates several artifacts because the job changes over time.
Consider a technical platform choice. The team may start with a short decision memo if the choice affects product strategy or cost. Once the technical path is chosen, an ADR should preserve the architecture reasoning. If the platform later causes reliability issues, the company needs an incident review or postmortem, not another strategy memo. The document should follow the operating need.
Artifact discipline is a leverage point because the right format shortens the path from context to action. The wrong format makes everyone read around the problem.
A simple routing rule helps. Use a memo before a choice, an FAQ after a decision starts creating repeated questions, an update when context changed but authority did not, an ADR when future operators need the reasoning, and a postmortem when reality has produced evidence. The rule does not need to be perfect. It only needs to stop teams from using the same document for every kind of work.
Evidence note: this post uses local Executive Communication, Right Depth for the Problem, and Productivity + Knowledge Management sources, plus public decision-record and RFC-style context including https://adr.github.io/ and https://www.rfc-editor.org/.
This is part 8 of 10 in Decision Memos and Written Operating Culture.