A Slack thread is not a decision record
A lot of technical consulting still settles important choices in chat: which CMS, which payment provider, whether the field app shares a session with the web app, what "done" means for a handover. The thread feels decisive while everyone is still in it. Six months later the studio asks why the catalog lives in Sanity instead of the theme, and the honest answer is buried in scrollback — or gone with free-plan retention. A Slack thread is a conversation. A decision record is the durable artifact you can hand to the next engineer without asking them to reconstruct intent from vibes.
The thread that felt like a decision
We see this most clearly when we sit behind a design studio. The room — or the channel — debates a seam for twenty minutes, someone says "let's go with X," a few thumbs-up land, and the build continues. That is fine as a coordination moment. It is not fine as the only record of why X won and Y lost.
Chat optimizes for speed and social proof. It does not optimize for alternatives considered, constraints that mattered, or the conditions under which you would reopen the choice. Those are the parts a later reader needs. Without them, every new person re-litigates the same fork, or silently invents a different rationale that steers the next change the wrong way.
Free Slack workspaces drop history after a short window. Even paid retention is not a search strategy. If the decision only exists as a thread, you have already decided that future you will not find it under deadline.
What the record has to carry
We keep the bar low on purpose. One decision, one short document next to the work: context, options that were real, the choice, and the consequences you are accepting. Status matters — Proposed, Accepted, Superseded — so the set stays a live map rather than a scrapbook.
The options section is where chat usually fails. A thread often records the winner and a joke about the loser. A useful record says which alternative you actually evaluated, what evidence you had, and why it lost. That is what stops the next workshop from spending a day rediscovering the same dead ends.
Write the revisit trigger in the same pass. "Revisit if wholesale accounts need a separate catalog" or "Revisit if PrintNode acceptance is no longer enough to trust paper" turns a frozen Accepted into something you can maintain. We already treat decision-log hygiene as ongoing work; the medium has to support that, and scrollback does not.
Announce in chat, file the record
Chat is still the right place to announce. Post the short version in the channel so the people who will live with the choice can push back while context is warm. Capture objections and constraints from that thread — they often add the real edge cases — then fold them into the record the same day.
Do not treat the announcement as the archive. The hybrid that works for us is deliberate → announce → write. Deliberation can happen in a call, a workshop, or even an AI-assisted comparison, as long as the durable output is a named decision with status. The channel gets the summary and a link. The repo or project docs get the artifact.
When we leave discovery, we already refuse to walk out with only a backlog. The same standard applies mid-build: a thumbs-up is not a signed decision, and a thread is not where signed decisions live.
Put it where the next person looks
Locality beats elegance. An ADR folder in the repo that owns the seam, a short page in the studio's project docs, or a decision section in the handover package — pick the place the next engineer will actually open. A beautiful Notion wiki nobody links from pull requests is almost as bad as Slack scrollback.
Reference the record from the work that depends on it. A PR that changes auth across web and field should cite the session decision. A CMS migration that touches product fields should cite the catalog ownership decision. Citations are how the record stays findable without relying on memory of channel names.
When a decision is superseded, do not rewrite history in place. Mark the old record Superseded, point at the new one, and leave the rationale intact. Future readers need both the current rule and the trail of why the rule changed.
What we refuse to treat as enough
A screenshot of a thread is not a decision record. Neither is a Loom where someone explains the choice once. Those are useful attachments. They still leave status, alternatives, and revisit conditions unstated.
A feature matrix from a bake-off is also not enough by itself — we have written about that separately — but at least it is an artifact you can attach. Chat has the opposite problem: high confidence, zero structure, and a retention policy working against you.
If the only place a consequential technical choice exists is in a messaging product, the consulting engagement has unfinished documentation work. Write the record before the channel goes quiet.
Questions
- Do we need a formal ADR template for every small choice?
- No. Use the form for consequential forks — data ownership, auth boundaries, vendor selection, irreversible side effects. Routine implementation details can stay in the PR. If someone six months later will ask "why this?", it belongs in a record.
- Where should the decision record live?
- Next to the work: an ADR folder in the relevant repo, or the project docs the studio and build partner already share. Link it from PRs and handovers. A separate wiki nobody opens under deadline is almost as bad as Slack scrollback.
- Is announcing in Slack still useful?
- Yes. Announce for pushback while context is warm, capture objections, then file the durable record the same day. Chat is the coordination layer; the record is the archive.
Sources
- Documenting architecture decisions — Microsoft Azure Architecture Center — Practical ADR fields: context, options, decision, consequences, status.
- Architecture Decision Records — Michael Nygard (Cognitect) — Origin of the lightweight ADR practice.
- Architecture Decision Records: A Practical Guide for 2026 — 2026 practice notes on narrow, honest, durable decision records vs tribal knowledge.